アクセスが少なければ速度は Unicorn > Passenger, アクセスが集中すると Unicorn < Passengerになる。どうしようかな
2012-03-02 14:09:44そもそもnginxに10workersも必要ないのではないか説。10個リクエストを受け付けて2個しかunicornがいなければそれは遅くなる、とか
2012-03-02 15:54:52@T_Hash Unicorn、1ワーカーが一度に処理できるのが1リクエストだけなので、秒間の同時アクセスがワーカー数*1ワーカーが1秒で処理できる数を超えるくらいになると当然待ちが発生するね。Rainbowsは1ワーカーが同時に複数リクエストをこなせるようにしている。
2012-03-02 15:03:06@faultier ありがとう。素Unicornのままだと大量リクエストに対して重くなったので、Rainbowsも試してみようかと思ってます。
2012-03-02 15:51:08@T_Hash Rainbowsが効いてくるのはI/O waitとかがボトルネックになってて、その待ってる間に他のリクエストを処理したい、みたいな時なので、Passengerで速くなるんだったらワーカー数増やせばUnicornでも速くなるんじゃないかなー
2012-03-02 15:55:56@T_Hash nginx自体は1ワーカーで複数リクエスト捌けるのでCPUのコア数と同じくらいで良くて、逆にunicornは1ワーカー1リクエストだからnginxのワーカー数よりも多くないと捌ききれなくなるんじゃない?
2012-03-02 16:02:34@faultier ぐは。そうですね..。最小ワーカー数>=CPUコア数、という記述をその数が「推奨」と読み違えていた疑惑が。であれば、最大ワーカー数はじわじわ増やしつつメモリサイズに応じて調整する感じ?
2012-03-02 16:13:54@T_Hash そうねー。Passengerだとむしろ速くなるのは「メモリやCPUのリソースが余ってて」「Apacheがある程度勝手にプロセス数増やしてくれる」からだから、増えた状態でサーバの負荷見て大丈夫そうならUnicornのワーカの数調整すればなんとかなる気がする。
2012-03-02 16:17:39@T_Hash 逆に、一個一個のリクエストの処理に時間がかかっていて詰まってるようなら、Rainbows!なら待ち時間に並行で処理してくれるから、そういうときに使う感じ。ただその分Unicornより仕組みが複雑だし、もっと後ろのDBとかで詰まってるなら逆効果だったりとか。
2012-03-02 16:19:23