Puma was running in cluster mode with one worker, which keeps a master
process holding a full copy of the preloaded app next to the worker.
Heroku counts both, so the 512 MB dyno sat at ~620 MB with a constant
R14. WEB_CONCURRENCY of 0 or 1 now runs one process with no master;
two or more workers still use cluster mode with preload_app!.
Puma reads WEB_CONCURRENCY itself, so single mode is set explicitly
with `workers 0`. Added a comment explaining the memory budget.
* Replace Sidekiq with Solid Queue
This commit transitions the background job processing from Sidekiq to
Solid Queue.
Changes:
- Replaced `sidekiq` gem with `solid_queue` in Gemfile.
- Updated `development.rb` and `production.rb` to use `:solid_queue` as
the queue adapter.
- Added Solid Queue database tables via a new migration.
- Configured Solid Queue in `config/queue.yml` and `config/recurring.yml`.
- Integrated Solid Queue supervisor as a Puma plugin in `config/puma.rb`.
- Removed separate worker process from `Procfile`.
- Removed Sidekiq-specific configuration files.
- Updated Gemfile.lock to support both `ruby` and `x86_64-linux` platforms.
Co-authored-by: CloCkWeRX <365751+CloCkWeRX@users.noreply.github.com>
* Fix regression in gemfiles
---------
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
Brenda Wallace