Nginxリクエスト/秒を最大化するためのヒント


15

分析パッケージを作成していますが、プロジェクトの要件では、1日あたり10億件のヒットをサポートする必要があります。うん、「億」。言い換えれば、1秒あたり12,000ヒット以上が持続し、できればバーストする余地があります。これには複数のサーバーが必要になることは知っていますが、「より多くのハードウェアを投入する」前に、各ノードのパフォーマンスを最大にしようとしています。

現在、ヒットトラッキング部分が完了し、最適化されています。リクエストをそのままRedisに保存するだけです(後でHadoopで処理するため)。アプリケーションは、ゲートウェイ用のgunicornを備えたPython / Djangoです。

私の2GB Ubuntu 10.04 Rackspaceサーバー(本番マシンではない)は、毎秒約1200個の静的ファイルを提供できます(単一の静的資産に対してApache ABを使用してベンチマーク)。比較すると、静的ファイルのリンクをトラッキングリンクと交換しても、1秒あたり約600のリクエストが発生します-これは、同じ静的アセットを提供するよりも2分の1だけ遅いため、トラッカーが最適化されていることを意味すると思います繰り返します。

ただし、数百万件のヒットでベンチマークを行うと、いくつかのことに気付きました-

  1. すべてのNginxログをオフにしているため、ディスク使用量はありません。カスタムコードはリクエストの詳細をRedisに保存するだけです。
  2. 一定ではないメモリ使用量-おそらくRedisのメモリ管理のため、私のメモリ使用量は徐々に上昇し、その後低下しますが、一度もボトルネックになったことはありません。
  3. システムの負荷は2〜4前後に留まり、最も重いベンチマークでもシステムは応答しますまた、(他の)サーバーが600リクエストを実行している間、目に見える遅延はほとんどなく、手動でhttp://mysite.com/tracking/pixelを表示できます秒。
  4. 短いテスト、たとえば50,000件のヒット(約2mを要する)を実行すると、安定した信頼性の高い1秒あたり600件の要求を受け取ります。より長いテストを実行すると(これまでに最大3.5mまで試行されました)、r / sが約250に低下します。

私の質問-

a。まだこのサーバーを使い切っているように見えますか?1,200 / sの静的ファイルnginxのパフォーマンスは、他の人が経験したものと同等ですか?

b。そのような大容量アプリケーション向けの一般的なnginxチューニングはありますか?私は64に設定されたワーカースレッドと8に設定されたgunicornワーカースレッドを持っていますが、これらの値を微調整してもあまり助けにも害にもならないようです。

c。着信接続を制限する可能性のあるLinuxレベルの設定はありますか?

d。長時間のテストでパフォーマンスが250r / sに低下する原因は何ですか?繰り返しますが、これらのテスト中にメモリが限界に達することはなく、HDDの使用はゼロです。

事前に感謝します、すべて:)

編集これ は私のnginxの設定です-http ://pastie.org/1450749-それはほとんどバニラで、明らかに脂肪が取り除かれています。


1つの投稿で複数の質問をしている場合は、修正を検討してください。私はすべての部分に答えることができないので、答えではなくコメントをしています。Python / Djangoのパフォーマンスを考慮していると思いますが、極端な速度には理想的ではありません。1200 req / sに関しては、1px gifまたはHTTP 204応答であると私が想定しているのは非常に低いようです。FXを参照してくださいsimonhf.wordpress.com/2010/10/02/nginx-versus-sxe-hello-world(24K REQ / sの、ローカルホスト上で実行されているが、わずか1つのnginxのワーカーを使用)
ジェスパーM

Goldmineのコメント、どうもありがとう。投稿を読んで、調査結果を表示します。「複数の質問」ポインターに感謝します!
-linkedlinked

回答:


8

Nginxのworker_threadsを悪用しています。それほど多くのワーカーを実行する必要はまったくありません。CPUの数だけワーカーを実行し、1日に呼び出す必要があります。同じサーバーでgunicornを実行している場合、おそらくnginxワーカーを2つに制限する必要があります。それ以外の場合は、これらすべてのプロセスを管理するために必要なすべてのコンテキストスイッチングでCPUをスラッシングするだけです。


1
ああ、ありがとう。パフォーマンスは64でも2とほぼ同じように見えましたが、WTFが実行していないことは知っていました。明確にしてくれてありがとう。
リンクリンク

Nginxの構成を共有できますか?チューニングの対象がわからない場合、チューニングのヒントを提供するのは困難です。
blueben

2

nginxを使用して、静的コンテンツの5Kリクエストを1秒で処理しました。現在1024に設定されているworker_connectionsの数を増やすことができます。

max_clientの計算は次のようになります。

メインセクションのworker_connectionsおよびworker_procesesを使用すると、maxclients値を計算できます。

max_clients = worker_processes * worker_connections

リバースプロキシの状況では、max_clientsは

max_clients = worker_processes * worker_connections / 4

http://wiki.nginx.org/EventsModule#worker_connections

最大ワーカー接続の計算は、セットアップの容量がわかれば簡単です。合計容量/コア数は、最大ワーカー接続数です。総容量を計算するには、複数の方法があります。

  1. 最も現実的な数値が得られるセットアップをベンチマークしてみることをお勧めします。Siege、Pummel、Apache Benchなどのツールを使用できますが、テスト中にシステムリソースの使用量を忘れずに測定してください。

上記の方法でうまくいかない場合は、以下の方法を試してください。RAMとIOを無視した幅広い仮定を行っていますが、これらも考慮に入れますが、これらは出発点を与え、そこから調整を行うことができます。

  1. 帯域幅がボトルネックであると仮定して、nginxが提供する平均オブジェクトサイズを取得し、それで帯域幅を分割すると、サポートされる最大のqpsが得られます。

  2. 2番目の仮定では、CPUがボトルネックです。この場合、要求時間を測定し、それで1をシステムのコアの数で割ります。これにより、nginxが処理できる1秒あたりのリクエスト数が得られます。


worker_connectionsを増やすことができるかどうか、および特定のサーバーの理想的な設定を判断するにはどうすればよいですか?
加藤

これにはいくつかの方法があります。
サミール
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.