rails のアプリケーションサーバについて

お久しぶりです。井出です。
前回の記事から１年経ちましたね。

今年もやってきましたアドベントカレンダー！
昨日は若手のホープ、ダニエル・バレンボイムが大好きなダニーさんが記事を書いてくれました。
記事はこちら

中途で入ったイケイケ系の彼ですが、
サーバばりばり触れるようになってきていて将来有望です！

入社してからの振り返り記事とのことで
プラコレが気になる方は、ぜひ雰囲気を感じてもらえたらと思います！

ダニーさんの流れで、自分も今年の振り返りをしてみようと思います。

去年まで自分のメイン言語はPHPでしたが、今年からRubyをメインにシステム開発していました。
記載方法が独特で最初は苦しめられましたが、振り返ってみると凄い楽しい言語です。
まだまだ理解できていない部分もあるので、来年はより深く理解できるよう進めていきます！

そんなこんなで、rubyのFWであるRailsで有名なサーバアプリケーション
puma / unicorn について、先日というか昨日なんですが
コマンドを調べる機会があったので
機能の違いとあわせてまとめてみようと思います。

unicornについて

前提：unicornはマルチプロセス/シングルスレッドです。

Unicornはプロセスごとに通信処理を行います。
そのため低速なio処理があった場合そこで足止めを食らい全体が重くなってしまいます。
これを回避するためにorkerの数を増やす必要がありますが
workerはCPUのコア数に依存する部分もあります。

コマンド

起動

bundle exec unicorn -E production -c config/unicorn.rb -D

-E 実行環境変数
-c 設定ファイルの位置
-D デーモン化

停止

kill -QUIT cat pidファイルのパス
kill -QUIT masterのpid

再起動

kill -HUP cat pidファイルのパス
kill -HUP masterのpid

緩やかな再起動

kill -USR2 cat pidファイルのパス
kill -USR2 masterのpid

旧プロセスを保持した状態で、新プロセスを起動
起動後旧プロセスに停止シグナル(QUIT)を実施し停止させる。

(仕様は https://github.com/phusion/unicorn 参考)

pumaについて

前提：pumaはマルチプロセス/マルチスレッドです。

rails5.2から標準機能となった。
リクエスト処理をスレッド単位で溜めて、それをマルチに実行することでの並列処理を可能としています。
リソースが少ない中でも効率的にリクエストをさばくことが可能になります。

コマンド

起動

bundle exec puma -C config/puma.rb -d

-C 設定ファイルの位置
-d デーモン化

停止

kill -QUIT cat pidファイルのパス
kill -QUIT masterのpid

再起動（設定ファイルリロード無）

kill -USR1 cat pidファイルのパス
kill -USR1 masterのpid

再起動（設定ファイルリロード有）

kill -USR2 cat pidファイルのパス
kill -USR2 masterのpid

使用用途によって使い分けることができれば素敵ですが
大規模システムでもない限り、パフォーマンスへの影響は無さそうですね。
こちらの記事が、両者の性能部分などをまとめてくださっています。

明日はフロントの将来有望株の好君が記事を書いてくれるので、ご期待を！
それではまた1週間後に会いましょう！

Now hiring！
プラコレでは、自由な未来をつくるために
一緒に冒険したいエンジニア・デザイナーを募集しています！
https://www.wantedly.com/projects/262436
運営サービス
PLACOLE(プラコレウェディング)
DRESSY(ドレシー)byプラコレ
farny(ファーニー)byプラコレ