次のように、Web サイトと同じサーバー上で Apache Bench を実行する場合:
ab -n 1000 -c 10 localhost:8080/
さまざまな場所からサーバーにアクセスするユーザーと比較すると、正確な結果が得られない可能性が高くなります。
中国のユーザーは同じ州/国のユーザーと比較してレイテンシーの問題が異なるため、これが実際のパフォーマンスにどのように、あるいはなぜ影響するかを理解しようとしています。
たとえば、Web サーバーの最大スレッド制限が 100 であるとします。
エンドユーザーのレイテンシーがサーバーのパフォーマンスにどのように影響するかを詳しく説明してくれる人はいますか。
ここでは、各リクエストが 10 ミリ秒ごとに均等に計算されると想定しています。
私が理解できないのは、外部要因、具体的にはインターネット接続 (場所、またはモバイルなどのデバイス) や http/tcp ハンドシェイクなどが、サーバー全体のパフォーマンスにどのように影響するかということです。
答え1
一般的に、エンド ユーザーのレイテンシはサーバーのパフォーマンスに影響しません。主な違いは、エンド ユーザーのレイテンシが高くなると、各接続の完了に少し時間がかかるため、サーバーが一度に持つ接続の数が増えることです。ただし、サーバーは各接続に対してほぼ同じ量の作業を行っています。サーバーの制限、主にメモリに達しない限り、問題にはなりません。
サーバーは、リクエスト全体を受け取るまで、接続のための負荷の高い作業を開始しません。そのため、接続の設定とリクエストの取得に時間がかかる場合、サーバーは実際の処理を実行する前に、基本的に何もせずに少し長く待機することになります。
通常、サーバーはリクエストを処理し、応答を 1 回でキューに入れます。クライアントとネットワークの待ち時間により、キューを空にするのに少し時間がかかる場合があります。ただし、これを処理するサーバーの部分は高度に最適化されており、特定のページまたはオブジェクトのロジックはすでに完了して応答を生成しています。したがって、この場合も、サーバーのパフォーマンスに大きな影響はありません。
ただし、クライアントのエクスペリエンスは大幅に悪くなる可能性があります。これは、クライアントがサーバーから情報を取得し、さらに情報を取得するためにサーバーに接続し直す必要があるケースがサービスに多くある場合に特に当てはまります。たとえば、Web ページがクライアントに多数のフレームをロードするように指示し、それらのフレームがクライアントに多数の画像をロードするように指示する場合、クライアントが結果を確認するまでに、多数の「往復」操作 (それぞれネットワーク遅延によって増加) が発生します。しかし、サーバーは同じ量の作業を行います。
答え2
実際には、リアルタイムで動作するマルチマルチプロセッサ (たとえば、1K CPU の数) と大量のメモリを搭載したスーパーコンピュータがない限り、これは問題にはなりません...
マルチプロセス システムではQuantum Size、すべてのプロセスに と呼ばれる時間枠があります。マルチプロセス機能を備えたオペレーティング システム (80 年代から 90 年代、そして今日まで) は、実行中のプロセス間を切り替えて、各プロセスに量子サイズを与えます。この時間枠は、現代のオペレーティング システムでは約 20 ミリ秒で、切り替えは非常に高速に行われ、切り替えのオーバーヘッドは非常に低くなっています。たとえば、CPU が 1 つあり、2 つのプロセスが 1 秒間 (1000 ミリ秒に相当) に切り替えられる場合、それらのプロセスは 900 ～ 950 ～ 980 (おそらく) ミリ秒実行できます (違いはプロセス切り替えによる)。とにかく、前述したように、この切り替えは非常に高速に行われ、50 のプロセスが実行中であると想像してください。すべてのプロセスが同時に実行されていることがわかります。実際にはそうではありません。これがマルチプロセスであり、プロセス スケジューリングの基本です...
プロセスに複数のスレッドがある場合、OS は最初にプロセスをスケジュールしてクォンタムを割り当て、次にそのプロセス内のスレッドをスケジュールします。そして、そのクォンタム内でスレッドもスケジュールされます。クォンタム全体が終了すると、OS は別のプロセス (またはスケジューリング アルゴリズムに従って同じプロセス) をスケジュールし、その新しいプロセス内のスレッドもスケジュールされます。
スレッドの実行環境には 2 つのレベルがあります。1 つはユーザー レベル、もう 1 つはカーネル レベルです。上で述べたのはユーザー レベルです。プロセス スケジューリング、スレッド スケジューリングは量子サイズで行われます。ただし、カーネル レベルに下がると、スケジューラは異なるプロセスから異なるスレッドをスケジュールできます。量子はカーネル レベルで直接スレッドに適用されます...
ここまで説明した内容を踏まえて、エンド接続の遅延がサーバーのパフォーマンスにどのように影響するかを理解していきましょう。
最高のパフォーマンスが必要な場合は、スレッドをカーネル レベルにする必要がありますが、Apache スレッドはカーネル モードではないことはわかっています。Apache 自体はユーザー モードです。これはユーザー エンド アプリケーションであり、そのスレッドはユーザー レベル モードで実行されます。したがって、そのサーバーから 100% のパフォーマンスを得ることはできません... スレッドがカーネル モードで実行されていて、CPU が 2 つあるとします。1 つのスレッドが最初の CPU 用、もう 1 つのスレッドが 2 番目の CPU 用です。これで、2 つのスレッドが同時に実行されます。Web ワーカー スレッドは、実際にはI/O BoundedOS の観点からはスレッドであり、何らかのファイルを要求すると、ファイルが準備されるまでブロックされます。スケジューラは、別のワーカー スレッドの実行をスケジュールします。「その」ファイルの準備ができると、ブロックされたスレッドは準備完了キューに移動し、再度スケジュールされます。これでうまくいきます... ワーカー スレッドが 100 個ある場合はどうなるでしょうか。この質問から別の質問が生まれます。ワーカー スレッドはいつ作成されるのでしょうか。
Web サーバー アプリケーションの場合、ワーカー スレッドは次の場合に作成されますlow-level IP connection is made。つまり、実際の 2 つのスレッドがすでに実行されており、ハードウェアによって新しい接続が確立され (独自の PU があり、データ情報転送のためにメイン システムに割り込む)、新しいワーカー スレッドがポップアップ表示され、スケジュールのために準備完了キューに送信されます...
メインテーマに戻りましょう。外部要因がシステム パフォーマンスにどのように影響するかです。すべてはシステムの制限に関することです。スレッド数は、システムがそれらを処理できる十分なプロセス ユニットを持っているかどうかでパフォーマンスに影響します。基本的な計算では、2 つのプロセッサは同時に 2 つのスレッドしか処理できません... ネットワーク接続帯域幅は、「いくつの接続を受け入れることができるか」によってパフォーマンスに影響します。接続データが 10 バイトで、帯域幅が 1 秒あたり 100 バイトの場合、1 秒あたり 10 の接続が可能です...
これらをスケーリングするのはあなた次第です。覚えておかなければならないことが 1 つあります。CPU リソース全体は、すでに準備完了キューにあるスレッドを処理しているということです。そのため、新しいスレッドがポップアップしても、現在のスレッドの状況が悪化することはありません。
サーバー アプリを初めて起動すると、パフォーマンスが問題になることがあります。すぐに最高速度に達します。これは車の加速に似ています。まず加速し、しばらくすると最高速度に達します。ガソリンがなくなるか、アクセル ペダルから足を離すまで、最高速度で走行できます。