Skip to content

[Dependashlee] Update to Puma 6.1.0 #23795

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

Merged
merged 2 commits into from
Feb 28, 2023
Merged

[Dependashlee] Update to Puma 6.1.0 #23795

merged 2 commits into from
Feb 28, 2023

Conversation

shleeable
Copy link
Contributor

@shleeable shleeable commented Feb 22, 2023

Note: puma supports websockets now.

https://github.com/puma/puma/releases/tag/v6.0.0
https://github.com/puma/puma/releases/tag/v6.0.1
https://github.com/puma/puma/releases/tag/v6.0.2
https://github.com/puma/puma/releases/tag/v6.1.0

5.0 to 6.0 Migration notes

Check the following list to see if you're depending on any of these behaviors:

  • Configuration constants like DefaultRackup removed, see #2928 for the full list.

  • We've removed the following public methods on Puma::Server: Puma::Server#min_threads, Puma::Server#max_threads. Instead, you can pass in configuration as an option to Puma::Server#new. This might make certain gems break (capybara for example).

  • We have changed the names of the following environment variables: DISABLE_SSL is now PUMA_DISABLE_SSL, MAKE_WARNINGS_INTO_ERRORS is now PUMA_MAKE_WARNINGS_INTO_ERRORS, and WAIT_FOR_LESS_BUSY_WORKERS is now PUMA_WAIT_FOR_LESS_BUSY_WORKERS.

  • Nakayoshi GC (nakayoshi_fork option in config) has been removed without replacement.

  • wait_for_less_busy_worker is now on by default. If you don't want to use this feature, you must add wait_for_less_busy_worker false in your config.

  • We've removed the following constants: Puma::StateFile::FIELDS, Puma::CLI::KEYS_NOT_TO_PERSIST_IN_STATE and Puma::Launcher::KEYS_NOT_TO_PERSIST_IN_STATE, and Puma::ControlCLI::COMMANDS.

  • We no longer support Ruby 2.2, 2.3, or JRuby on Java 1.7 or below.

  • The behavior of remote_addr has changed. When using the set_remote_address header: "header_name" functionality, if the header is not passed, REMOTE_ADDR is now set to the physical peeraddr instead of always being set to 127.0.0.1. When an error occurs preventing the physical peeraddr from being fetched, REMOTE_ADDR is now set to the unspecified source address ('0.0.0.0') instead of to '127.0.0.1'

  • Previously, Puma supported anything as an HTTP method and passed it to the app. We now only accept the 8 HTTP methods defined in RFC 9110.

@shleeable shleeable marked this pull request as draft February 22, 2023 04:14
@shleeable shleeable marked this pull request as ready for review February 23, 2023 03:17
@shleeable shleeable changed the title Update to Puma 6.1.0 [Dependashlee] Update to Puma 6.1.0 Feb 23, 2023
@shleeable
Copy link
Contributor Author

shleeable commented Feb 23, 2023

@Gargron @ClearlyClaire I have tested with on my dev instance without issue (for me with my limited knowledge).

I'm going to continue to test this, but I don't think any of the breaking changes affect Mastodon.

@ClearlyClaire
Copy link
Contributor

We should investigate the effects of

We've removed the following public methods on Puma::Server: Puma::Server#min_threads, Puma::Server#max_threads. Instead, you can pass in configuration as an option to Puma::Server#new. This might make certain gems break (capybara for example).

We do use capybara in tests, and we set min and max threads in config/puma.rb though not through the listed methods, so it may be fine, but we'd better double-check.

@shleeable
Copy link
Contributor Author

shleeable commented Feb 24, 2023

@ClearlyClaire the threads part looks fine... can't speak to capybara

with WEB_CONCURRENCY=6 and MAX_THREADS=10

6.1.0

=> Booting Puma
=> Rails 6.1.7.2 application starting in production
=> Run `bin/rails server --help` for more startup options
[7] Puma starting in cluster mode...
[7] * Puma version: 6.1.0 (ruby 3.0.5-p211) ("The Way Up")
[7] *  Min threads: 10
[7] *  Max threads: 10
[7] *  Environment: production
[7] *   Master PID: 7
[7] *      Workers: 6
[7] *     Restarts: (✔) hot (✖) phased
[7] * Preloading application
[7] * Listening on http://0.0.0.0:3000
[7] Use Ctrl-C to stop
[7] - Worker 0 (PID: 11) booted in 0.04s, phase: 0
[7] - Worker 1 (PID: 29) booted in 0.04s, phase: 0
[7] - Worker 2 (PID: 47) booted in 0.03s, phase: 0
[7] - Worker 3 (PID: 54) booted in 0.02s, phase: 0
[7] - Worker 4 (PID: 83) booted in 0.01s, phase: 0
[7] - Worker 5 (PID: 101) booted in 0.0s, phase: 0

5.6.5

=> Booting Puma
=> Rails 6.1.7.2 application starting in production
=> Run `bin/rails server --help` for more startup options
[7] Puma starting in cluster mode...
[7] * Puma version: 5.6.5 (ruby 3.0.5-p211) ("Birdie's Version")
[7] *  Min threads: 10
[7] *  Max threads: 10
[7] *  Environment: production
[7] *   Master PID: 7
[7] *      Workers: 6
[7] *     Restarts: (✔) hot (✖) phased
[7] * Preloading application
[7] * Listening on http://0.0.0.0:3000
[7] Use Ctrl-C to stop
[7] - Worker 0 (PID: 11) booted in 0.05s, phase: 0
[7] - Worker 1 (PID: 24) booted in 0.04s, phase: 0
[7] - Worker 2 (PID: 47) booted in 0.03s, phase: 0
[7] - Worker 3 (PID: 60) booted in 0.02s, phase: 0
[7] - Worker 4 (PID: 83) booted in 0.01s, phase: 0
[7] - Worker 5 (PID: 96) booted in 0.0s, phase: 0

@xrobau
Copy link
Contributor

xrobau commented Feb 24, 2023

FYI, This PR has been running fine on dev.mastodon.au for a few days with zero issues that I've noticed, and no unexpected errors in syslog.

@vmstan
Copy link
Contributor

vmstan commented Feb 24, 2023

Testing on half of vmst.io now.

CleanShot 2023-02-24 at 08 12 13@2x

@shleeable
Copy link
Contributor Author

I'll leave this to the devs.. but this looks good

@vmstan
Copy link
Contributor

vmstan commented Feb 26, 2023

Rolled all of vmst.io up and no issues.

Copy link
Contributor

@xrobau xrobau left a comment

Choose a reason for hiding this comment

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

Confirm approve

Copy link
Contributor

@ClearlyClaire ClearlyClaire left a comment

Choose a reason for hiding this comment

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

I have verified the MIN_THREADS and MAX_THREADS settings work as expected. In addition, I have verified we don't use the capybara gem in a way that breaks.

LGTM

@ClearlyClaire ClearlyClaire merged commit f8848a5 into mastodon:main Feb 28, 2023
@shleeable shleeable deleted the patch-13 branch February 28, 2023 23:17
skerit pushed a commit to 11ways/mastodon that referenced this pull request Jul 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants