0

小さな静的xmlファイル〜40k / sをサーバーする必要があるプロジェクトに取り組んでいます。

すべての受信リクエストは、HAProxy からサーバーに送信されます。ただし、永続的なリクエストはありません。

問題は、非永続的なリクエストでベンチマークを実行すると、nginx インスタンスが 19 114 リクエスト/秒で上限に達することです。永続的な接続を有効にすると、パフォーマンスがほぼ 1 桁向上し、168,867 リクエスト/秒になります。結果は G-wan と同様です。

非永続的なリクエストをベンチマークする場合、CPU 使用率は最小限です。

非永続的な接続と nginx でパフォーマンスを向上させるにはどうすればよいですか?


[root@spare01 lighttpd-weighttp-c24b505]# ./weighttp -n 1000000 -c 100 -t 16 "http://192.168.1.40/feed.txt"
finished in 52 sec, 315 millisec and 603 microsec, 19114 req/s, 5413 kbyte/s
requests: 1000000 total, 1000000 started, 1000000 done, 1000000 succeeded, 0 failed, 0 errored
status codes: 1000000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 290000000 bytes total, 231000000 bytes http, 59000000 bytes data




[root@spare01 lighttpd-weighttp-c24b505]# ./weighttp -n 1000000 -c 100 -t 16 -k "http://192.168.1.40/feed.txt"
finished in 5 sec, 921 millisec and 791 microsec, 168867 req/s, 48640 kbyte/s
requests: 1000000 total, 1000000 started, 1000000 done, 1000000 succeeded, 0 failed, 0 errored
status codes: 1000000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 294950245 bytes total, 235950245 bytes http, 59000000 bytes data
4

1 に答える 1

0

あなたの 2 つのテストは似ています (HTTP Keep-Alive を除く):

 ./weighttp -n 1000000 -c 100 -t 16 "http://192.168.1.40/feed.txt"
 ./weighttp -n 1000000 -c 100 -t 16 -k "http://192.168.1.40/feed.txt"

また、HTTP Keep-Alive を使用したものは 10 倍高速です。

finished in 52 sec, 19114 req/s, 5413 kbyte/s
finished in 5 sec, 168867 req/s, 48640 kbyte/s

まず、HTTP Keep-Alives(永続的な接続) HTTP リクエストの実行を高速化する理由は次のとおりです。

  • がないHTTP Keep-Alivesと、クライアントは各要求に対して新しい CONNECTION を確立する必要があります (これは TCP ハンドシェイクのために低速です)。

  • を使用HTTP Keep-Alivesすると、クライアントはすべての要求を一度に送信できます (SAME CONNECTION を使用)。やるべきことが少ないので、これはより高速です。


次に、静的ファイルの XML サイズが「小さい」と言っています。

「小さい」は 1 KB または 1 MB に近いですか? わかりません。しかし、それは物事をスピードアップするために利用可能なオプションに関して大きな違いをもたらします.

巨大なファイルはsendfile()カーネルで動作するため、通常は処理され、ユーザーモード サーバーはディスクからの読み取りとバッファリングの負担から解放されます。

小さなファイルは、ユーザーモードでアプリケーション開発者が利用できるより柔軟なオプションを使用できますが、ここでもファイルサイズが重要です (バイトとキロバイトは別物です)。


3 番目に、テストで 16 のスレッドを使用しています。クライアント マシンとサーバー マシンの両方を本当に楽しん16 PHYSICAL CPU Coresでいますか?

そうでない場合は、Web サーバーをテストしていないところまでテストの速度を落としているだけです。


ご覧のとおり、多くの要因がパフォーマンスに影響を与えます。さらに、OS のチューニング (TCP スタック オプション、利用可能なファイル ハンドル、システム バッファなど) もあります。

システムを最大限に活用するには、これらすべてのパラメーターを調べて、特定のエクササイズに最適なものを選択する必要があります。

于 2013-05-12T08:36:29.500 に答える