この記事では、リバースエンジニアリングに挑戦してみよう、と言う人もいるかもしれません。私たちは各 Web サーバーの内部に手を染め、誰も悪用しない方法でサーバーを悪用します。
このテストは真空中で球状の馬を測定したものであり、得られたデータにすぎず、それをどう扱うべきかはわかりません。
方法論
Nginx と Apache のオペレーティング システムは、IIS Windows Server Core 18.04 用の Ubuntu 2019 LTS です。テスト前に、すべてのオペレーティング システムは 04.12.2019 年 XNUMX 月 XNUMX 日の時点で最新の更新プログラムを受信していました。
テストは HTTP 経由のみで実行されました。各 Web サーバーは、Codrops の無料の Jekyll テンプレートである同じページを実行しました。 。各 Web サーバーでは gzip 圧縮が無効になっていました。
スループット テストは、引数を指定した Httpd-tools を使用して実行されました。
ab -n 50000 -c 500 http://192.168.76.204:80/サーバーは、10、5、および 1 コアのコアの 8、4、および 9900% に制限されていました。テストベンチは 5400K@10MHz のコンピューターでした。これは、540% 制限を受信するサーバーがコアあたり約 XNUMXMHz を受信することを意味します。
TTFB テストは、サーバーの最初の起動時に実行され、DevTools を使用して測定されました。結果を受け取った後、サーバーはオフになり、あらゆる種類のキャッシュが表示されないようにするために前のチェックポイントにロールバックされました。
テスターと Web サーバーは同じホスト上、同じ仮想スイッチ上にありました。
ディスク サブシステムをすぐに評価するには、ボトルネックを把握するために ATTO および CrystalDIskMark ベンチマークの結果を使用します。
仮想マシンから取得されたデータ:
結果：
TTFB：
IIS の平均 TTFB は最小の 0,5 ミリ秒ですが、Apache では 1,4 ミリ秒、Nginx では 4 ミリ秒です。
スループット：
まず、各サーバーがコアの数に基づいてどの程度拡張できるかを見てみましょう。
グラフには、Web サーバーに対するテスターの呼び出し数と遅延が表示されます。グラフは、NGINX がすべてのリクエストの 98% を処理し、20 ミリ秒以内にサイトを配信したことを示しています。 IIS は、Apache と同様に、すべての呼び出しの最後の 5% をそれぞれ 76 ミリ秒と 14 ミリ秒で完了しました。
グラフは、ストレス テスト中の 1 つのリクエストの平均処理時間を示しています。
グラフからわかるように、IIS は Apache と Nginx の両方を圧倒し、高負荷時に大幅に速度が低下しました。
IIS は明らかに 4 コアよりも XNUMX コアを優先し、XNUMX コアのほうが遅延が低いことが示されましたが、XNUMX コアを強く支持するわけでもありませんでした。
NGINX は 8 コアすべてにわたって適切に拡張でき、Apache の場合はシングルコアのシナリオが最良の選択であるようです。
スケーラビリティ：
nginxの：
次に、周波数とコア数の観点からスケーラビリティを見てみましょう。
Nginx は、1 コアと 4 コアの 1% の制限があるテストに合格しませんでした。リクエストが 2000 を超えると、テスターとの接続が終了しました。
Apache：
Apache は、Nginx と同様に、2500 件のリクエストを処理した後、諦めて接続を閉じました。 Apache は 8、4、1 コアの制限 1% でテストに不合格でしたが、さらに 5 コアの制限 XNUMX% でテストにも不合格となり、これは Nginx よりも悪いです
IIS：
テスト中、IIS はリクエストの巨大なキューを蓄積しましたが、それぞれを処理しました。どうやら、初期状態ではリクエスト処理にタイムアウトは設定されていないようです。
グラフは、テストが完了するまでにかかった時間を示します。まったく不合理なテスト構成は破棄されました。この図は、ハードウェアに関して IIS がいかに要求が厳しいか、そして NGINX がいかに素晴らしいかを示しています。
ディスクからのスケーラビリティ:
nginxの：
次に、周波数、コア数、ディスク速度の観点からスケーラビリティを見てみましょう。
今回、Nginx は 4 つではなく XNUMX つのテストに失敗しました。
Apache：
Apache は前回と同じ数のテストに失敗しました。
IIS：
IIS では、ディスク制限がないかのように、ほぼ同じグラフが表示されます。一般に、すべてのサーバーのグラフィックスはあまり変化しませんでした。これは、各サーバーが静的データを RAM にキャッシュし、そこから提供したことを意味します。ここで主なボトルネック、つまり Web サーバー自体がわかります。
このテストに基づいて結論を出すのは時期尚早です。Let's Encrypt のライブ証明書を使用した HTTPS、圧縮、および HTTP/2 はまだテストされていません。これについては次の記事で説明します。
出所： habr.com