Per-process config vars
agrobbin opened this issue · 1 comments
Required Terms
- I agree to follow this project's Code of Conduct
- I have read and accept the Salesforce Program Agreement
What service(s) is this request for?
Heroku dynos
Tell us about what you're trying to solve. What challenges are you facing?
Often times, different processes need different configuration, particularly when it comes to scaling different types of processes independently. Puma and Sidekiq, combined with Rails' threading configuration and DB pools is a good example.
The standard configuration for a Rails app is to drive concurrency based on the WEB_CONCURRENCY and RAILS_MAX_THREADS environment variables, which are used to control things like Puma workers / threads, Sidekiq concurrency, and DB connection pool size. However, the concurrency someone chooses for each of these will likely vary significantly per-process.
Since each process can run on different dyno types, how you scale a process within a dyno will not be the same across processes. Puma may make sense to configure with WEB_CONCURRENCY of 8, and RAILS_MAX_THREADS of 5, while Sidekiq may make sense to configure with a RAILS_MAX_THREADS of 10.
Currently, we achieve this by explicitly setting RAILS_MAX_THREADS in our Procfile for certain process types, and leave the Heroku-managed WEB_CONCURRENCY and RAILS_MAX_THREADS config vars as the ones that control our web process.
It would be preferred to be able to manage these entirely through Heroku config vars, to take advantage of no-build configuration updates across all configurations.
Thank you for your suggestion @agrobbin. Making config vars more versatile, along with restricting access to its secrets, are considerations for improvement of config vars.