Webrickを本番サーバーとして使用してはならないのは当然のことのようですが、その理由について言及しているところはどこにも見つかりません。コンセンサスは次のように思われます。「Webrickは開発には問題ありませんが、ThinまたはUnicornが生産期間の選択です。」
シンサーバーのホームページを調べて、リクエスト/秒について話しましたが、注釈がないため、グラフがよくわかりません。
Webrickと比較してThinまたはUnicornを使用する理由を誰かに教えてもらえますか？また、開発にWebrickを使用することにメリットはありますか？レールが付属しているのでWebrickを使用していますが、これがデフォルトであるのには理由があるはずです。
ちなみにHerokuを使用しています。
いくつかの重要な理由
リダイレクト/リライトについて言及するときは、Webrickを使用すると、別のレイヤー（Rack、Sinatra、Rails、カスタムWebrickコードなど）でリライトを処理する必要があるという事実を指します。これには、リライトコードを実行するために、追加のルビー「ハンドラー」を起動する必要があります。トラフィックの少ないサイトの場合、事前にウォームアップされたプロセスがまだ何もしていない可能性があるため、これで問題ない場合があります。ただし、トラフィックの多いサイトの場合、これはフロントエンドサーバー（Apache、Nginxなど）がRuby *を起動せずに処理できるサーバーへの余分な負荷であり、おそらく桁違いに高速です。
*たとえば、ロードバランサーの背後で実行している場合、すべての書き換えトラフィックをrubyがインストールされていないサーバーにルーティングし、メインサーバーにプライマリトラフィックのみを管理させることができます。この書き換えトラフィックは、SEOのサイト変更などが原因である可能性があります。別のケースは、複数のコンポーネントを持つサイトであり、おそらく1つのセクションがRailsで、別のセクションがPHPであり、両方に対して書き換えが必要です（つまり、古いPHPパスをRailsに書き換えます）。
WEBrickはより長いURIも処理できません。それらが2083文字を超えると、クラッシュが発生します。Thinにはこれらの問題がないため、Thinは優れています-すでに開発中です。
単純なことや時期尚早の最適化を複雑にするのは本当に好きではありません。WEBrickは、トラフィックの少ないWebサイトであれば、本番環境で使用できます。ほとんどのアプリケーションはです。
電子メールの送信やPDFファイルの生成など、サイトで時間がかかる場合は、WEBrickをマルチスレッドにする必要があります。一度に複数のリクエストを処理したい。
過去にセキュリティ上の問題が発生しましたが、本番用のサーバーに比べて非常に遅いことが大きな理由のようです。
本番モードで実行する場合のwebrickの最大の弱点は、シングルスレッドのシングルプロセスWebサーバーであるということです。つまり、一度に1つのhttpリクエストしか処理できません。