Railsでよく使うWebサーバ「puma」の備忘記事。「Pumaってどんな設定が必要だったかなー」という時に見るといい感じ。
GitHub - puma/puma: A Ruby/Rack web server built for parallelism
A Ruby/Rack web server built for parallelism. Contribute to puma/puma development by creating an account on GitHub.
github.com
設定の解説
起動方法
$ puma -C config/puma.rb「-C」でPumaの設定ファイルを指定することが可能。
よく使う設定の解説（config/puma.rb）
設定の全量がこちら。
app_path = File.expand_path('..', __dir__)
max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
# スレッドプールの設定。
# 最小と最大を同じにすることで、トラフィック増加時にスレッド起動時の負荷をなくす。
threads min_threads_count, max_threads_count
environment ENV.fetch("RAILS_ENV") { ENV['RACK_ENV'] || "production" }
pidfile "#{app_path}/tmp/pids/server.pid"
# workerの数。CPUのコア数と同じする。
workers ENV.fetch("WEB_CONCURRENCY") { 2 }
# アプリの事前ロード。Workerの起動時間を短くすることが可能。
preload_app!
# Workerが起動されリクエスト受諾前に行う処理を記載する。
on_worker_boot do
# config/database.yml に記載のpoolサイズのコネクションを張る。
ActiveRecord::Base.establish_connection
end
bind "unix://#{app_path}/tmp/sockets/puma.sock"
# tmp_restart: Pumaの再起動を可能にするプラグイン。
plugin :tmp_restart
threads、workers
workerプロセス1つにつき、threadsで設定されたスレッドを持つ。そのため、1度に処理できるリクエスト数は、「workers数 × threads数」となる。
チューニングのポイントになる設定。
workersはCPUコア数よりも少なく設定するのが推奨。
threadsはデフォルトの5が推奨（以下、公式サイトより）。ここからアプリの様子を見てチューニングしていく必要がある。
puma/docs/deployment.md at master · puma/puma
A Ruby/Rack web server built for parallelism. Contribute to puma/puma development by creating an account on GitHub.
github.com
例：workers 2、threads 2, 2の場合
2（workers）× 2 (スレッド最大数) = 4（リクエスト/回）
→1回あたり4リクエスト処理可能。
preload_app!
fork前にアプリをロードすることで、メモリ使用量を減らすことができる。
on_worker_boot do 〜 end
Workerが起動してリクエスト受諾前に行う処理を記載する。ここでは、DBコネクションを張る（ActiveRecord::Base.establish_connection）処理をしている。コレ意外に処理を追加するとしたら、Redis等のキャッシュストレージのコネクション接続ぐらいかなー。
bind “unix://#{app_path}/tmp/sockets/puma.sock”
NginxとUNIXソケット連携させるための設定。UNIXソケットの方がTCPよりもパフォーマンスがよい。UNIXソケットは早い反面、NginxとRailsアプリが同一サーバとか、ECSだとNginxとRailsアプリのタスクを一緒にする必要があるなど制約あり。
コメント