34

RailsサーバーとしてUnicornとThinを使用することについて、人々の意見を聞きたかっただけです。私がオンラインで見つけた記事/ベンチマークのほとんどは非常に不完全であるように見えるので、それについて議論するための集中的な場所があればいいと思います.

Unicron はマルチプロセス サーバーですが、thin はイベント ベースのノンブロッキング サーバーです。イベントベースのサーバーは素晴らしいです...コードが非同期/非ブロックの場合-バニラレールがブロックされています. したがって、ノンブロッキング Rails ライブラリを使用しない限り、Thin を使用する利点はわかりません。さらに悪いことに、非ブロッキング サーバーでは、i/o ループがブロックされている場合、ループ全体がブロックされ、ブロッキング呼び出しが戻るまでそれ以上の要求を処理できなくなります。ブロッキング ライブラリの速度が低下します。

Heroku がデフォルトのサーバー (cedar 用) として Thin を選択したのはなぜですか? 彼らは頭がいいので、彼らには理由があったと思います。

以下は、Thin を 4 つの Unicorn ワーカーに置き換えることを提案するリンクです。これは私にとって完全に理にかなっています。 Heroku 上の 4 つの Unicron ワーカー

4

3 に答える 3

25

Thin は設定が簡単で、最適ではありませんが、Heroku 環境で動作します。

Unicorn はより効率的ですが、構成する必要があります: ワーカーは何人ですか? アプリをプリロードしますか? あなたは何を選びますか？

私はワーカーを 3、5、8 に設定した Unicorn Heroku アプリをリリースしました。これは、各アプリの大きさ、コードの量、メモリの使用量、トラフィックの量に基づいて、この数値を選択するために必要です。時間をかけて監視して、正しい数を取得し、アプリでメモリが不足していないことを確認します。

Preload false - これによりアプリの起動が遅くなりますが、Unicorn がワーカーを再起動すると、ネットワーク接続 (memcache、postgres、mongo など) で「より安全」になります。

Preload true - これはより良いですが、フォークの前後のコードでサーバーの再接続を正しく処理する必要があります。

Thin にはすぐに使用できるこれらの問題はありませんが、実行プロセスのみが得られます。

概要: Unicorn をすぐに使えるように (またはまったく) 万人向けに構成するのは非常に困難ですが、Thin はより少ないサポート リクエストで人々を稼働させることができます。

于 2012-12-25T01:00:08.297 に答える
13

最近 (ほんの数か月前)、Phusion Passengerの背後にいる人々が Heroku にサポートを追加しました。間違いなく、これはあなたのニーズに合っているかどうか試してみる必要がある代替手段です.

1ダイノでも爆速で、応答時間の低下は明白です。シンプルなPassenger Ruby Heroku デモが github でホストされています。

Passengers on Heroku が主張する主な利点は次のとおりです。

  • Nginx による静的アセット アクセラレーション- Ruby アプリに静的アセットを提供させるのではなく、Nginx に任せて、本当に重要なタスクのためにアプリをオフロードします。Nginxははるかに優れた仕事をします。

  • 複数のワーカー プロセス- 1 つの dyno で 1 つのワーカーのみを実行する代わりに、Phusion Passenger は 1 つの dyno で複数のワーカーを実行するため、そのリソースを最大限に活用し、費用対効果を高めます。このアプローチはユニコーンのアプローチに似ています。ただし、Unicorn とは異なり、Phusion Passenger は現在のトラフィックに基づいてワーカー プロセスの数を動的にスケーリングするため、リソースが不要な場合は解放されます。

  • メモリーの最適化- Phusion Passenger は、Thin や Unicorn よりも少ないメモリーを使用します。また、コードのプリロードと組み合わせてコピー オン ライトの仮想メモリもサポートしているため、Ruby 2.0 で実行した場合のアプリのメモリ使用量がさらに少なくなります。

  • 要求/応答のバッファリング - 含まれている Nginx は要求と応答をバッファリングするため、遅いクライアント (モバイル ネットワーク上のモバイル デバイスなど) からアプリを保護し、パフォーマンスを向上させます。

  • アウトオブバンド ガベージ コレクション- Ruby のガベージ コレクタは遅いのに、長い応答時間で訪問者を悩ませるのはなぜでしょうか? 通常の要求と応答のサイクル以外でガベージ コレクションを実行することで、これを修正してください。Unicorn によって最初に導入されたこの概念は改善されました。Phusion Passenger は、同時に 1 つの要求のみが帯域外ガベージ コレクションを実行することを保証し、Unicorn の帯域外ガベージ コレクションが持つすべての問題を排除します。

  • JRuby のサポート- Thin よりも Unicorn の方が適していますが、JRuby はサポートされていません。Phusion Passengerはそうです。

お役に立てれば。

于 2014-02-13T04:49:23.710 に答える
9

Heroku はインテリジェント ルーティングを使用しません。dyno がビジーかどうかに関係なく、dyno にランダムにジョブを割り当てます。したがって、dyno が一度に複数のジョブを処理できない場合、無料の他の多数の dyno に料金を支払っていたとしても、レイテンシー (おそらく、膨大なレイテンシー) が発生します。「そうです。アプリにインテリジェント ルーターで 80 の dyno が必要な場合、ランダム ルーターでは 4,000 が必要です。」 http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics

Heroku はこれに取り組んでおり、彼らの計画は Unicorn を使いやすくすることだと述べています。彼らは基本的にこう言いました。私たちがずっと推し進めてきたものです。」 http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics

公式の Heroku の説明 (上記の 2 番目のリンク) から:ピューマやユニコーンのようなサーバー。

Thin を使用して Cedar にデプロイされた Rails アプリは、すぐにリクエスト キューイングの問題を引き起こす可能性があります。Cedar ルーターはアプリに代わってキューイングを行わなくなったため、dyno でキューイングされたリクエストは、単一の Rails プロセスがキューを通過するまで待機する必要があります。多くの顧客がこの問題に遭遇しましたが、私たちは対策を講じることができず、Cedar に Rails アプリをデプロイするためのより良いアプローチを提供することができませんでした。」

また興味深いのは、New Relic を含むパフォーマンス ツールが dyno キューで費やされた時間を報告していないことです。 http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

おっとっと。

于 2013-11-13T22:41:03.123 に答える