Enable puma clustered #654
Conversation
| # Use the `preload_app!` method when specifying a `workers` number. | ||
| # This directive tells Puma to first boot the application and load code | ||
| # before forking the application. This takes advantage of Copy On Write | ||
| # process behavior so workers use less memory. |
There was a problem hiding this comment.
In puma 5 preloading app is the default behaviour
| # process behavior so workers use less memory. | ||
| # | ||
| # preload_app! | ||
| workers ENV.fetch("WEB_CONCURRENCY") { 3 } |
There was a problem hiding this comment.
@DeeDeeG if you could share with me some data about the workload in production would be nice, and I could help to improve this setup.
There was a problem hiding this comment.
@brunoocasali hmm, I don't have access to that data myself.
cc @mi-wood @tkwidmer do you have data about our traffic/resource usage on Heroku?
This pull request is to look at enabling multiple workers/concurrency in Puma. It would be useful to know what our performance needs are. If you have anything relevant to share from the Heroku dashboards, that would be great.
Thanks.
There was a problem hiding this comment.
If you people use any APM will be nice to see them too, like new relic, scout apm or others..
DeeDeeG
added
Hacktoberfest
|
Merging this to I might revert this just before publishing a new release, then revert the revert again so it stays live on staging. That is, I'd like to try this out and be sure it works well for a while before putting this change on the main site. But I'm happy to begin trying it out now! Thanks again! |
This reverts commit 6c63546. We don't know for sure that we need these speed/latency gains, and maintenance bandwidth is low for the project. We don't want to potentially have to track down bugs, or undo any damage done, so revert this change for now.
This reverts commit 6c63546. We don't know for sure that we need these speed/latency gains, and maintenance bandwidth is low for the project. We don't want to potentially have to track down bugs, or undo any damage done, so revert this change for now.
* Enable puma clustered (#654) Enable puma clustered mode to process more requests and reduce latency * Use a volume to deal with bundled gems (#640) This way we don't need to rebuild everytime we add/update/remove a gem * Improve organization in contact/restroom models (#653) * Remove unused git keep from models * Improve identation/organization of Contact form * Improve Restroom model organization by grouping method kinds * Update dependencies for early March 2021 (#658) * Dockerfile: Update NodeJS to version 14 * yarn.lock: Bump ini from v1.3.5 to v1.3.8 * yarn.lock: Bump dompurify from v2.0.8 to v2.2.6 * Gemfile.lock: Bump nokogiri from 1.10.10 to 1.11.1 * Gemfile[.lock]: Update rails to v5.2.4.5 Was version 5.2.4.4 (this is a patch version bump) * Ruby: Update from 2.5.8 to 2.6.6 * Gemfile[.lock]: Update webmock (v3.2.1 to v3.12.1) Also update its transitive dependencies, within ranges allowed by Gemfile. * Ruby: Update from 2.6.6 to 2.7.1 * Ruby: Update from 2.7.1 to 2.7.2 * Gemfile.lock: Update puma from 5.0.2 to 5.2.2 * yarn.lock: Update elliptic from v6.5.3 to v6.5.4 * Revert "Enable puma clustered (#654)" (#659) This reverts commit 6c63546. We don't know for sure that we need these speed/latency gains, and maintenance bandwidth is low for the project. We don't want to potentially have to track down bugs, or undo any damage done, so revert this change for now. Co-authored-by: Bruno Casali <brunoocasali@gmail.com>
Based on: #641
This PR just enable the puma clustered mode as discussed in #641 (comment)