Puma

https://puma.io/images/logos/puma-logo-large.png

pumaをMRIで実行する場合、DB待ちなどは別スレッドが動きますがGiant VM Lockの都合で1プロセスでは1コアしか使いきれないので、CPUコア数分のpumaのワーカープロセスを立ち上げることが多いですね…

1プロセスのスレッド数にも上限設定があるので、DB待ちが長い場合などはコア数より少し多めにワーカープロセス起動することもあります

スレッド数の上限を上げる手もありますが、上げすぎるとそれはそれで効率が落ちるとpumaのドキュメントに書かれていた記憶

pumaはIO待ちが処理時間の多くを占める場合でないとスレッドを増やしてもスループットは変わりませんでした

例えばIO待ちがなく10msかかる処理を3スレッドで処理する場合は、それぞれが遅くなって30msかかるようになります（そのかわりほぼ同時に終わる）

pumaはリクエストのバッファリングがあるのもunicornとの違いだという認識です。

これのお陰で処理が詰まってもアプリケーションが502が返すケースがほとんどなくて、代わりにtimeoutや処理時間の増加などには気を遣う必要があるかと

このへんは単純にunicorn/pumaどちらが優れているというよりは、インフラ含めてのアーキテクチャの設計としてユースケースに応じて選択するものだと思ってます (edited)