search

heroku / roadmap

This is the public roadmap for Salesforce Heroku services.
194 stars 0 forks source link

Per-process config vars #267

Open agrobbin opened 9 months ago

agrobbin commented 9 months ago

Required Terms

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.

andre5oto commented 8 months ago

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.