Windows は Apache の ab を使用してサーバーをテストしました
ab -c 100 -n 1000 http://www.xxxxx.com
1 秒あたりに処理されるリクエストの数はわずか 20 であることがわかり、その他の待機時間は nginx のデフォルトの同時実行性が非常に高いことを意味するわけではありません。
それでも、1 秒あたりに処理されるリクエストの数と同時実行性は同じ概念ではありません。
1 秒あたりのプロセス数同時実行ストレス テスト道を空けてください。 。 。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
1つのサーバーの状況についてのみ話します。
同時実行数は、クライアントの観点から見た、同時に到着するリクエストの数を指します。サーバーの同時処理能力は、理想的には (プロセスの切り替えなしで) 同時に処理できるリクエストの数を指します。同時実行性 処理能力は CPU のコア数と同じです。
上記の内容に基づいて、8 つのコアがあり、要求されたタスクが IO のない純粋なコンピューティング タスクである場合、各コアは明らかに 1 秒あたり 1 つ以上のリクエストを処理できると仮定します。この数字が完全に可能であれば、このサーバーは 1 秒あたり 80,000 件のリクエストを処理できます。
ここで io を追加します。CPU が IO 中に待機する必要があり、他のことができない場合、CPU が 1 秒あたりに処理できるリクエストの数は明らかに大幅に減少し、おそらく 10,000 から数百、場合によっては数十、数になります。
次に、プロセスの切り替えやアルゴリズムの効率などのさまざまな要素を 1 つずつ追加すると、複雑ですが実際のサーバーが得られます。
これらは同じ概念ではありませんが、関連しています:
c を増やす過程で注意しなければならないことの 1 つは、スレッド/プロセスの数が増えるほど、コンテキストの切り替えとスレッド/プロセスのスケジューリングのオーバーヘッドが増加することです。これにより、t の値が大幅かつ間接的に増加し、q が妨げられることになります。 c の値は比例して増加するため、c をむやみに増加しても、通常は良い結果が得られません。実験に基づいて最適な c 値を取得する必要があります。平均応答時間を t (単位はミリ秒)、同時実行性を c、1 秒あたりに処理されるリクエストの数を q と仮定すると、次のようになります:
q = (1000/t) * cこれは次のとおりです。
考える q を増やすには 2 つの方法しかありません: 1) t を下げる 2) c を増やす
'1' については、コードを最適化することによってのみ達成できます。多くの場合、制限されます。
「2」の場合、通常は c サーバー プログラムのリクエスト処理モデルに関連し、サーバー プログラムが「1 つのスレッドに 1 つのリクエストに対応する」モードの場合、c の最大値は制限されます。サポートできるスレッドの数。「1 つのプロセスが 1 つのリクエストに対応する」モードの場合、c の最大値はプロセスの最大数に依存します。
さらに、特別な状況があります。サーバーによって提供されるサービスが「データ量が少なく、応答時間が長い」という特徴があると企業が判断した場合、つまり、ビジーではないが非常に遅いビジネスタイプです。 、その後、NIO を使用できます。モードはサービスを提供します。たとえば、nginx はデフォルトで nio モードを使用します。
このモードでは、c 値はスレッド/プロセスの数には関係せず、「ソケット接続の数」にのみ関係します。通常、「ソケット接続の数」は非常に大きくなる可能性があり、特別に構成された Linux サーバーでは、同時に数百万のソケット接続がサポートされます。このような高い c 値では、c は 100 万に達する可能性があります。 t がどれほど大きくても、非常に高い q をサポートできます。同時に、CPU 使用率を最大化するために、実際のスレッド/プロセスの数は CPU コアの数と一致するようにのみ開くことができます。もちろん、これらすべての前提となるのは、ビジネスが「データ量が少なく、応答時間が長い」という特性を持っているということですWeb サイトが静的サイトであり、すべてのリクエストが nginx を経由すると仮定します。その後、テスト マシンとサーバー間のネットワーク通信がスムーズであることを確認する必要があります。 ab のようなツールはストレス テストにはあまり説得力がありません。jmeter またはloadrunner をお勧めします。ストレス テスト中は、テスト対象のサーバーの実際のパフォーマンスとみなされる前に、テストの応答時間曲線が一定期間安定していることを確認する必要があります。これは、一定のウォームアップ時間がかかるためです。通常、一定時間経過後に曲線が安定してから、現在の応答時間を判断します。
1 秒あたりのリクエスト = 一定期間内に完了したリクエストの総数 / 時間
同時実行の量は、現在維持されている接続の数です。
netstat -netを介してすべての接続を表示します。例:
リーリー