プロダクションサーバーとしてのWebrick対ThinまたはUnicorn？

Webrickを本番サーバーとして使用してはならないのは当たり前のようですが、理由を述べているところはどこにもありません。コンセンサスは「Webrickは開発に問題はないが、ThinまたはUnicornが生産期間の選択である」と思われる。

シンサーバーのホームページを調べたところ、リクエスト数/秒について話していましたが、注釈がないためグラフがよくわかりません。

Webrickと比較してThinまたはUnicornを使用する理由を誰かに教えてもらえますか？また、開発にWebrickを使用するメリットはありますか？私はレールが付属しているのでWebrickを使用してきましたが、それがデフォルトである理由はあるはずだと思います。

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

いくつかの重要な理由

1. Rubyで書かれている（http://github.com/ruby/ruby/tree/trunk/lib/webrickを参照）
2. 編集されているため、複数のワーカー（特に、事前フォーク、ライフサイクル管理、非同期処理など）、リダイレクト、書き換えなど、プロダクションWebサイトが通常必要とする多くの機能はありません。

リダイレクト/リライトについて言及するときは、Webrickを使用する場合、別のレイヤー（Rack、Sinatra、Rails、カスタムWebrickコードなど）でリライトを処理する必要があることを指します。これには、書き換えコードを実行するために、追加のルビ「ハンドラー」を起動する必要があります。トラフィックの少ないサイトの場合、事前にウォームアップされたプロセスが何も実行していない可能性があるため、これで問題ありません。ただし、トラフィック量の多いサイトでは、これはフロントエンドサーバー（Apache、Nginxなど）がRuby *を起動せずに処理できるものに対するサーバーの余分な負荷であり、おそらく桁違いに高速です。

* たとえば、ロードバランサーの背後で実行している場合、すべての書き換えトラフィックを、rubyがインストールされていないサーバーにルーティングし、メインサーバーがプライマリトラフィックのみを管理するようにすることができます。この書き換えトラフィックは、SEOのサイト変更または類似したものによる可能性があります。別のケースは、複数のコンポーネントを持つサイトであり、おそらく1つのセクションがRails、もう1つがPHPであり、両方に書き換えが必要です（つまり、古いPHPパスをRailsに書き換えます）。

WEBrickは、長いURIも処理できません。2083文字を超えると、クラッシュが発生します。Thinにはこれらの問題がないため、優れています。すでに開発中です。

単純なことや時期尚早な最適化を複雑にすることはあまり好きではありません。WEBrick は、トラフィックの少ないWebサイトであれば、本番環境で使用できます。ほとんどのアプリケーションはそうです。

電子メールの送信やPDFファイルの生成など、サイトで時間がかかる処理を行う場合は、WEBrickをマルチスレッド化する必要があります。一度に複数のリクエストを処理したい。

過去にいくつかのセキュリティ問題がありましたが、大きな理由は、本番用のサーバーと比較して非常に遅いためです。

プロダクションモードで実行する場合のwebrickの最大の弱点は、シングルスレッド、シングルプロセスのWebサーバーであることです。つまり、一度に1つのHTTPリクエストしか処理できません。