4 ms·
Database locks is our issue. We're doing anywhere from 5-10k req/s to our RDBMS. This could be minimized if not completely avoided, and I'm keen to make it so,
by joshmn 4y ago
Database locks is our issue. We're doing anywhere from 5-10k req/s to our RDBMS. This could be minimized if not completely avoided, and I'm keen to make it so, but I got here a bit late and the underlying foundation of our application isn't something I can safely describe.
Most of our work happens in the background. We're running a Sidekiq process per CPU core with a concurrency of 20 — which, while the default, seemed to play the best during our tests. We set a max RSS of 2000 and use some code to automatically scale Heroku based on queue size. We do a lot of network IO.
It was a headache to get here, and a hole in our wallet, but I'm mostly happy with the application. Previously, we were running Resque in production on a super over-provisioned AWS node that was costing us $xx,xxx a month: Resque forks the app process for concurrency (we weigh about 450 MB); Sidekiq is a threaded model. Heroku, at least in this case, has been exponentially cheaper. We keep our RDS on AWS for at least some savings versus having it on Heroku. I cannot imagine what a xx-TB database would cost us at Heroku.