docs/6.0-Upgrade.md
Puma 6 brings performance improvements for most applications, experimental Rack 3 support, support for Sidekiq 7 Capsules, and more.
Here's what you should do:
For a complete list of changes, see History.md.
Puma 6 is mostly about a few nice-to-have performance changes, and then a few breaking API changes we've been putting off for a while.
We've improved throughput and latency in Puma 6 in a few areas.
wait_for_less_busy_worker was an experimental feature in Puma 5 and it's now the default in Puma 6. This feature makes each Puma child worker in cluster mode wait before listening on the socket, and that wait time is proportional to N * number_of_threads_responding_to_requests. This means that it's more likely that a request is picked up by the least-loaded Puma child worker listening on the socket. Many users reported back that this option was stable and decreased average latency, particularly in environments with high load and utilization.Rack 3 is now out and we've started on Rack 3 support. Please open a bug if you find any incompatibilites.
Sidekiq 7 (releasing soon) introduces Capsules, which allows you to run a Sidekiq server inside your Puma server (or any other Ruby process for that matter). We've added support by allowing you to pass data into run_hooks, see issue #2915.
Check the following list to see if you're depending on any of these behaviors:
DefaultRackup removed, see #2928 for the full list.DISABLE_SSL is now PUMA_DISABLE_SSL, and MAKE_WARNINGS_INTO_ERRORS is now PUMA_MAKE_WARNINGS_INTO_ERRORS.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 0 in your config.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).Puma::StateFile::FIELDS, Puma::CLI::KEYS_NOT_TO_PERSIST_IN_STATE and Puma::Launcher::KEYS_NOT_TO_PERSIST_IN_STATE, and Puma::ControlCLI::COMMANDS.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'HEAD GET POST PUT DELETE OPTIONS TRACE PATCH
supported_http_methods in your config file, see Puma::DSL#supported_http_methods.Then, update your Gemfile:
gem 'puma', '< 7'