3

最近、展開サーバーに Nginx + Thin をインストールしましたが、これが最後の要求と応答の状況でどのように機能するかわかりません。毎秒 1000/req としましょう。

そのため、シンの速度は1秒あたり10〜100リクエストで良好です

リクエスト/レスポンス クラスタで処理される大量のデータについて知りたいと思っていました。

これについて私を案内してください:-)

4

2 に答える 2

3

複数のシン プロセスと nginx は、アプリケーションの実行内容に応じて、多くの速度を提供できます。したがって、問題はアプリケーション コード、アプリケーション サーバーの速度、およびデータベース サーバーになります。

Scaling Rails については、 Scaling Rails Screencastsで最近詳しく説明されています。そこから始めることをお勧めします。Rails をスケーリングするための私の 5 ステップのプログラムは次のようになります。

  1. 最初のステップは、アプリケーションで何が遅いかを調べるためのツールを用意することです。問題が何であるかわからない場合は、アプリケーションのすべてを最適化するのに時間を費やさないでください。
  2. 1 秒間に大量のリクエストを処理できるようにする最も簡単な方法は、ページ キャッシュを使用することです。
  3. それができない場合は、可能な限りすべてをキャッシュして (フラグメント キャッシュ、memcached を使用してデータをキャッシュするなど)、アプリケーションを高速化します。
  4. その後、アプリケーションを可能な限り最適化し、SQL クエリを高速化し、すべてのインデックスを作成します。
  5. それでも速度が必要な場合は、問題にさらに多くのハードウェアを投入してください。大規模で強力なデータベース サーバーと多数のアプリ サーバーを用意し、それらの間でリクエストをプロキシします。ここから始めることもできますが、最適化プロセスが遅れるだけです。
于 2009-02-17T05:50:12.827 に答える
0

単一のサーバーを使用している場合、主な鍵は、既に述べたすべてのものとは別に、その仕様を軽視しないことだと思います. 多すぎて少なすぎて実行しようとすると、災害のレシピにすぎません.

monit または God にシン インスタンスを監視させるのも良い考えです。私は God から始めましたが、Ruby 1.8.6 ではメモリ リークがかなりひどくなったので、monit を優先して使用をやめました。Monit は CI で書かれており、メモリ フットプリントが小さいので、CI をお勧めします。

nginx とシンをうまく使いこなすのに少しばかりのように思える場合は、Passenger や LiteSpeed などのオールインワン ソリューションを検討することをお勧めします。私はこれらの経験がほとんどないため、実質的なアドバイスを提供することはできません.

于 2009-02-19T05:59:56.343 に答える