Puma config that draws on the cpu assignment to determine workers #1595
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR re-draws the puma config in ETEngine to use the cpu assignment of the container to determine workers (if WEB_CONCURRENCY is not set explicitly).
This is more of an 'example' PR for now. Before merging this PR, we should also correctly set the WEB_CONCURRENCY variable or remove it as per this issue.
If we would like to move forward with adjusting the puma configurations in our other rails applications, for the thread-safe applications (ETModel and MyETM at least) we can also allow the threads assignment in their puma configurations to be determined buy the cpu_cores assignment, matching the number of threads and workers to the number of cpus available, or explicitly setting the RAILS_MAX_THREADS variable to limit threads explicitly.
This PR also introduces
preload_app!
to the puma config which helps save memory between workers using copy on write. This seems to make sense in any case where more than one worker might be used.