Page MenuHomePhabricator

Raise bullseye maximum concurrent database connections
Open, Needs TriagePublic

Description

Hello,

I would like to request an increase to the maximum simultaneous database connections for the bullseye toolforge project. The nature of the tool is that users will often open multiple tabs at once (one per IP they're querying) and each of these connections is querying the database to check user permissions and update my query count trackers. Caching could help with the permission queries (though an experiment in using Django's local-memory cache did not work out) but will not improve the query count tracking. The nature of the database access will be quite bursty and short: get current user permissions, update them if needed, update query counts, done. I'll take whatever you are willing to give, but I think a max of 20-25 would alleviate most of the issues. Happy to answer questions, and I am definitely open to alternatives if there's something I haven't thought of.

Event Timeline

Please see Data-Services (Quota-requests) for the template to request this type of quota change.

Thanks @bd808 - I didn't see that, so I was following the "request a memory increase" template. The page you linked me to says that only requests for changes to wiki replica connections are being considered, and this request is about an increase in connections to toolsdb; should I just close this ticket as "not going to happen"?

@GeneralNotability we have technical challenges if nothing else on increasing connections to toolsdb. The hoped for future solution to this is actually replacing the monolithic toolsdb system with individual Trove instances for tools. If you are interested in the pain experience of being the first tool to attempt to go in that direction we could talk about that. I can't make an guarantees on how quickly the WMCS team would be able to partner with you to figure it out however. Trove is generally available for Cloud VPS projects, but we have only talked in theory so far about how to use it from Toolforge (which is technically the "tools" Cloud VPS project).

Other options to consider:

  • Offload your stats tracking to use Redis as a queue and some background/cron process to bulk update your tool db
  • Change the permissions check from using local db as cache to working directly from the API response

This isn't a time-critical issue, so I would be happy to be a guinea pig for working with WMCS to figure this out. And from what I've read online, the "right" approach here generally would involve memcached, but as far as I can tell that isn't available to toolforge projects.

And from what I've read online, the "right" approach here generally would involve memcached, but as far as I can tell that isn't available to toolforge projects.

The Toolforge redis server should mostly be a suitable replacement for memcached use-cases.

Thanks @Legoktm, I wasn't aware of that, will give it a try. I don't think it'll solve all the problems without a major overhaul of my code to do what bd808 suggested earlier with the queue + bulk write, but it should improve things a bit.