Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #28955 - Add puma configuration tuning options #790

Merged
merged 1 commit into from
Feb 19, 2020

Conversation

sthirugn
Copy link
Contributor

@sthirugn sthirugn commented Jan 23, 2020

I am creating this PR sooner with DO NOT MERGE tag to let everyone know how I am proceeding.
Any feedback is appreciated.

About the configuration file puma_production.erb

  • I have so far picked only 2 parameters - threads and workers. More will be picked in the future if need be. See sample config for more info.

Pending work in this PR

  • Externalize the parameters in the template (as environment variables?)
  • workers=4 is my test configuration. I need to test further to tune this to an appropriate default value.

ensure => directory,
}

file { "${::foreman::app_root}/config/puma/production.rb":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should actually live in http://github.com/theforeman/foreman. Since it's Ruby, it can use ENV and we can set that in our systemd overrides. This way container deployments can also benefit from this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe like creating puma/production.rb in https://github.com/theforeman/foreman/tree/develop/config. If so, where will the template (templates/puma_production.erb) live?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can avoid to template it. In pure Ruby:

# Configure "min" to be the minimum number of threads to use to answer
# requests and “max” the maximum.
#
# The default is "0, 16".
#
threads ENV.fetch('FOREMAN_PUMA_THREADS_MIN', 0).to_i, ENV.fetch('FOREMAN_PUMA_THREADS_MAX, 16).to_i


# === Cluster mode ===

# How many worker processes to run.
#
# The default is "0".
#
workers ENV.fetch('FOREMAN_PUMA_WORKERS', 4).to_i

Untested, but I suspect this will work. Then you should be able to set these environment variables via systemd overrides.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ekohl I tried the configuration you gave above in /usr/share/foreman/config/puma/production.rb

I provided overrides in file /usr/share/foreman-installer/modules/foreman/templates/foreman.service-overrides.erb like the following:

[Service]
User=<%= scope['foreman::user'] %>
Environment=FOREMAN_ENV=<%= scope['foreman::rails_env'] %>
Environment=FOREMAN_HOME=<%= scope['foreman::app_root'] %>
<% if scope['foreman::foreman_service_bind'] -%>
Environment=FOREMAN_BIND=<%= scope['foreman::foreman_service_bind'] %>
<% end -%>
Environment=FOREMAN_PORT=<%= scope['foreman::foreman_service_port'] %>
Environment=FOREMAN_PUMA_WORKERS=8
Environment=FOREMAN_PUMA_THREADS_MIN=4
Environment=FOREMAN_PUMA_THREADS_MAX=12

Initially I thought it was working, but later figured that it is not really picking up the environment variable values defined. I am looking into this further.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding notes from discussion, I tested this method out and it worked great for me. We will want a Redmine issue since we'll be adding a baseline configuration file to Foreman core codebase as well as this overrides file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ehelms thank you for the test. Added redmine issue and updated this PR and the foreman-installer PR. Added link below in the comment section.

@sthirugn sthirugn changed the title [DO NOT MERGE] Initial commit for puma configuration Added puma configuration Feb 6, 2020
@sthirugn
Copy link
Contributor Author

sthirugn commented Feb 6, 2020

This is ready for review in conjunction with theforeman/foreman-installer#464 theforeman/foreman#7421

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should also add the values to manifests/init.pp.

@sthirugn sthirugn changed the title Added puma configuration Fixes #28955 - Added puma configuration Feb 10, 2020
@ehelms
Copy link
Member

ehelms commented Feb 10, 2020

Something to consider is the db pool size we used given the threading nature of Puma. We likely want to tune this based on these settings.

https://devcenter.heroku.com/articles/concurrency-and-database-connections

@sthirugn sthirugn changed the title Fixes #28955 - Added puma configuration [DO NOT MERGE] Fixes #28955 - Added puma configuration Feb 11, 2020
@sthirugn
Copy link
Contributor Author

You should also add the values to manifests/init.pp.

Thank you, @ekohl I added params to init.pp and confirmed that I can override them through custom-hiera.yaml parameters like the following:

# cat /etc/foreman-installer/custom-hiera.yaml | tail -n 3
foreman::foreman_puma_threads_min: 1
foreman::foreman_puma_threads_max: 14
foreman::foreman_puma_workers: 6

@ekohl
Copy link
Member

ekohl commented Feb 11, 2020

It shouldn't be needed to specify it via hiera and should show up as --foreman-foreman-puma-threads-min.

manifests/init.pp Outdated Show resolved Hide resolved
manifests/init.pp Outdated Show resolved Hide resolved
@sthirugn
Copy link
Contributor Author

It shouldn't be needed to specify it via hiera and should show up as --foreman-foreman-puma-threads-min.

Good to know this.

@sthirugn
Copy link
Contributor Author

Something to consider is the db pool size we used given the threading nature of Puma. We likely want to tune this based on these settings.

https://devcenter.heroku.com/articles/concurrency-and-database-connections

I am testing with different configurations. I will post here when I have more info.

@sthirugn
Copy link
Contributor Author

Updated default puma workers to 2 as per theforeman/foreman#7421 (comment)

@sthirugn sthirugn changed the title [DO NOT MERGE] Fixes #28955 - Added puma configuration Fixes #28955 - Added puma configuration Feb 12, 2020
Copy link
Member

@ehelms ehelms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The failures are unrelated and same as master. @ekohl good with this?

@@ -193,6 +193,12 @@
#
# $cors_domains:: List of domains that show be allowed for Cross-Origin Resource Sharing. This requires Foreman 1.22+
#
# $foreman_service_puma_threads_min:: Minimum number of threads for puma. Relevant only when Puma service is used and ignored when Passenger is used.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bit of a bikeshedding: should this leave out puma in the variable name? The use of puma vs Puma is also a bit inconsistent.

Suggested change
# $foreman_service_puma_threads_min:: Minimum number of threads for puma. Relevant only when Puma service is used and ignored when Passenger is used.
# $foreman_service_threads_min:: Minimum number of threads for Puma. Relevant only when Puma service is used and ignored when Passenger is used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think calling out puma explicitly in the variable name will help the users under it as puma threads vs. just foreman threads.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ekohl Updated lowecase/uppercase inconsistencies, let me know what you think

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the last item, I think this is good to be merged.

# $foreman_service_puma_threads_max:: Maximum number of threads for Puma. Relevant only when Puma service is used and ignored when Passenger is used.
#
# $foreman_service_puma_workers:: Number of workers for Puma. Relevant only when Puma service is used and ignored when Passenger is used.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The empty line here breaks some tools. The comment block must be attached to the class.

Suggested change
#

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, fixed it now. thanks!

@ekohl
Copy link
Member

ekohl commented Feb 19, 2020

Tests are still running. The person merging this should make sure to squash the commits.

@sthirugn sthirugn force-pushed the puma_config branch 3 times, most recently from afa2997 to d1ceb50 Compare February 19, 2020 17:24
@ehelms
Copy link
Member

ehelms commented Feb 19, 2020

Same failures as master, mergin

@ehelms ehelms merged commit 94e03d5 into theforeman:master Feb 19, 2020
@ekohl ekohl changed the title Fixes #28955 - Added puma configuration Fixes #28955 - Add puma configuration tuning options Feb 19, 2020
@ekohl
Copy link
Member

ekohl commented Feb 19, 2020

@sthirugn the dash in the commit message appears to be needed for the PR processor. Now it wasn't checked. I also didn't check during the review, but let's be mindful about this in the future. Now it didn't hard fail because this repo doesn't hard require a Redmine issue.

@sthirugn sthirugn deleted the puma_config branch February 19, 2020 20:31
@sthirugn
Copy link
Contributor Author

@sthirugn the dash in the commit message appears to be needed for the PR processor. Now it wasn't checked. I also didn't check during the review, but let's be mindful about this in the future. Now it didn't hard fail because this repo doesn't hard require a Redmine issue.

ack thank you for pointing this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants