WEBサーバーの戦い。 パート 2 – 現実的な HTTPS シナリオ:

でテクニックについて話しました 最初の部分 この記事では、より現実的なシナリオで HTTPS をテストします。 テストのために、Let's Encrypt 証明書を取得し、Brotli 圧縮を 11 に有効にしました。

今回は、サーバーを VDS 上に展開するシナリオ、または標準プロセッサを搭載したホスト上の仮想マシンとして展開するシナリオを再現してみます。 この目的のために、制限は次のように設定されました。

• 25% - これは、約 1350 MHz の周波数に相当します。
• 35% -1890MHz
• 41% - 2214MHz
• 65% - 3510MHz

500 回限りの接続数が 1 から 3、5、7、9、XNUMX に減りました。

結果：

遅延:

HTTPD ツールは個別のリクエストごとに新しいユーザーを作成するため、TTFB は特に別個のテストとして組み込まれました。 ユーザーは依然として数ページをクリックするため、このテストは依然として現実から切り離されており、実際には TTFP が主要な役割を果たします。

最初のリクエスト (通常、IIS 仮想マシンの最初の起動後の最初のリクエスト) には平均 120 ミリ秒かかります。

後続のすべてのリクエストの TTFP は 1.5 ミリ秒です。 Apache と Nginx はこの点で遅れをとっています。 個人的に、著者はこのテストが最も明らかであると考えており、これに基づいてのみ勝者を選択するつもりです。
IIS はすでに圧縮された静的コンテンツをキャッシュし、アクセスされるたびにそれを圧縮するわけではないため、この結果は驚くべきことではありません。

クライアントごとに費やされる時間

パフォーマンスを評価するには、1 つの接続を使用したテストで十分です。
たとえば、IIS は 5000 ユーザーのテストを 40 秒で完了しました。これは 123 秒あたり XNUMX リクエストに相当します。

以下のグラフは、サイトのコンテンツが完全に転送されるまでの時間を示しています。 これは、一定時間内に完了したリクエストの割合です。 この例では、すべてのリクエストの 80% が IIS では 8 ミリ秒、Apache と Nginx では 4.5 ミリ秒で処理され、Apache と Nginx ではすべてのリクエストの 8% が最大 98 ミリ秒以内に完了しました。

5000 件のリクエストが処理された時間:

5000 件のリクエストが処理された時間:

3.5 GHz CPU と 8 コアを搭載した仮想マシンがある場合は、必要なものを選択してください。 このテストでは、すべての Web サーバーが非常に似ています。 各ホストに対してどの Web サーバーを選択するかについては、以下で説明します。

もう少し現実的な状況になると、すべての Web サーバーが対決します。

スループット：

遅延と同時接続数のグラフ。 滑らかで低いほど良いです。 最後の 2% は、判読できなくなるため、チャートから削除されました。

次に、サーバーが仮想ホスティングでホストされるオプションを考えてみましょう。 4 GHz の 2.2 コアと 1.8 GHz の XNUMX コアを考えてみましょう。

スケーリング方法

真空三極管や五極管などの電流-電圧特性がどのようなものかを見たことがあれば、これらのグラフには見覚えがあるでしょう。 これが私たちが捉えようとしているもの、つまり飽和です。 限界は、コアをどれだけ投入してもパフォーマンスの向上が顕著に感じられないときです。

以前は、曲線を可能な限り平坦に保ち、すべてのリクエストの 98% を最小のレイテンシーで処理することが全体の課題でした。 次に、別の曲線を作成して、各サーバーの最適な動作点を見つけます。

これを行うには、XNUMX 秒あたりのリクエスト数 (RPR) インジケーターを使用してみましょう。 横軸は周波数、縦軸は XNUMX 秒あたりに処理されるリクエストの数、行はコアの数です。

Nginx がリクエストを次々に処理する方法の相関関係を示します。 このテストでは 8 コアの方がパフォーマンスが優れています。

このグラフは、Nginx が単一コア上でどれほど優れた (それほどではない) 動作をするかを明確に示しています。 Nginx を使用している場合、静的なコアのみをホストしている場合は、コアの数を XNUMX つに減らすことを検討する必要があります。

IIS は、Chrome の DevTools によると TTFB が最も低いにもかかわらず、Apache Foundation のストレス テストとの真剣な戦いで Nginx と Apache の両方になんとか負けています。

グラフの曲率もすべて鉄壁に再現されています。

ある種の結論:

はい、Apache は 1 コアと 8 コアでは動作が悪くなりますが、4 コアでは少し良く動作します。

はい、8 コアの Nginx は、1 コアと 4 コアではリクエストを次々とより適切に処理しますが、接続が多い場合は動作が悪くなります。

はい、IIS はマルチスレッド ワークロードの場合は 4 コアを優先し、シングルスレッド ワークロードの場合は 8 コアを優先します。 最終的に、IIS は、すべてのサーバーが同等であったにもかかわらず、高負荷時に 8 コアで他のサーバーよりわずかに高速でした。

これは測定誤差ではなく、誤差は +-1ms 以内です。 遅延は少なく、RPR のリクエストは 2 秒あたり +- 3 ～ XNUMX 件以下です。

8 コアのパフォーマンスが低下するという結果は、まったく驚くべきことではありません。パイプライン全体を完了しなければならない時間枠がある場合、多くのコアと SMT/ハイパースレッディングはパフォーマンスを大幅に低下させます。

出所： habr.com