[解決済み] ウェブリックを本番サーバーにする vs. シンかユニコーンか？

質問

Webrick を本番用サーバとして使ってはいけないというのは当たり前のような気がしますが、その理由を書いているところがありません。コンセンサスは次のようなものだと思われます。 Webrick は開発用として OK ですが、本番環境では Thin または Unicorn を選択する必要があります。

私は Thin サーバーのホームページを調べ、それはリクエスト/秒について話しますが、注釈がないので、私はグラフを本当に理解していません。

Webrick と比較して、なぜ Thin または Unicorn を使用する必要があるのか、どなたか教えていただけませんか。また、開発用に Webrick を使用する利点はありますか。私はrailsに付属しているときからWebrickを使用していますが、それがデフォルトである理由があるはずだと思うのです。

ちなみに私はHerokuを使っています。

どのように解決するのですか？

いくつかの重要な理由

1. Rubyで書かれていること ( http://github.com/ruby/ruby/tree/trunk/lib/webrick )
2. 編集 マルチワーカー（特にプリフォーク、ライフサイクル管理、非同期処理など）、リダイレクト、リライトなど、本番用Webサイトに通常必要な機能があまり備わっていない。

リダイレクト/リライトについて言及するとき、Webrick を使用すると、別のレイヤー (Rack, Sinatra, Rails, カスタム Webrick コードなど) でリライトを処理しなければならないという事実を指しています。このため、書き換えコードを実行するために、追加の ruby "handlers" をスピンアップする必要があります。トラフィックの少ないサイトでは、すでに何もしていないプロセスがあらかじめ用意されている可能性があるため、これは問題ないかもしれません。しかし、トラフィックの多いサイトでは、フロントエンド サーバー (Apache、Nginx など) が Ruby* をスピンアップせずに処理でき、おそらく桁違いに高速であるため、これはサーバーへの余分な負荷となります。

* たとえば、ロード バランサーの背後で実行している場合、すべての書き換えトラフィックを ruby がインストールされていないサーバーにルーティングし、メイン サーバーに主要なトラフィックのみを管理させることができます。この書き換えトラフィックは、SEOのためのサイト変更などによるものかもしれません。また、複数のコンポーネントを持つサイトで、あるセクションはRails、別のセクションはPHPで、両方の書き換えが必要な場合（古いPHPのパスをRailsに書き換えるなど）にも有効でしょう。