Last I wrote we
were (almost) mangling the
DATABASE_URL on Heroku to get the connection pool size we wanted for both Puma and Sidekiq.
Since then, Heroku came out with a DevCenter article that found the right bits in Rails to get the database config settings (I swear, I looked!) and I could see the error of my ways.
So, without further ado, let’s look at the changes.
First, I ditched the
set_db_connection_pool_size! method in
Platform and created an initializer.
You can see that we make sure to
disconnect after Rails is done initializing the app.
Then, we reconnect specifically for Puma to match its
max_threads setting. After that,
do the same for Sidekiq and we’re good to go.
Not nearly as ugly and doesn’t hack an
ENV var. I think it’s a nice compromise.
What else does this help?
I had a hunch it was from having a
DATABASE_URL env var, so I was extra motivated to refactor this.
Hope that helps!
This was deployed to production yesterday, and we haven’t seen any issues.- Jesse