NGINX (SSL) => VARNISH (CACHE) => APACHE/PHP で実行されるアプリケーションがあります。
ランニングABベンチマークEC2 t2.small インスタンスを介して、varnish レイヤー (HTTP 経由) で 30,000 件以上のリクエスト / 秒を達成できます。ただし、NGINX (HTTPS) 経由でテストを実行すると、160 件のリクエスト / 秒しかプッシュできません (パブリック Web からの TTFB の平均は 43 ミリ秒)。
nginx.conf で
user nginx;
worker_processes auto;
worker_rlimit_nofile 65535;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 16024;
multi_accept on;
}
http レベルでは:
sendfile on;
tcp_nopush on;
keepalive_timeout 10;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
@ ドメイン.conf
server {
listen 443 ssl;
server_name xyz.com;
ssl_certificate /home/st/ssl3/xyz.crt;
ssl_certificate_key /home/xyz/ssl3/xyz.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
ssl_session_tickets on;
location / {
proxy_buffers 8 8k;
proxy_buffer_size 2k;
proxy_pass http://127.0.0.1:79;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_redirect off;
}
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
}
Apacheのベンチマークはこちら
内部 => @APACHE:
Concurrency Level: 10
Time taken for tests: 0.694 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1002
Keep-Alive requests: 996
Total transferred: 705122 bytes
HTML transferred: 401802 bytes
Requests per second: 1440.93 [#/sec] (mean)
Time per request: 6.940 [ms] (mean)
Time per request: 0.694 [ms] (mean, across all concurrent requests)
Transfer rate: 992.22 [Kbytes/sec] received
Varnish のベンチマークは次のとおりです (以前は 20 ～ 30k で実行されていました - CPU サイクルを使い果たしました。平均 ATM は 4 ～ 8k rps です)
内部 => @VARNISH => @APACHE:
Concurrency Level: 10
Time taken for tests: 0.232 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 23439800 bytes
HTML transferred: 23039412 bytes
Requests per second: 4310.16 [#/sec] (mean)
Time per request: 2.320 [ms] (mean)
Time per request: 0.232 [ms] (mean, across all concurrent requests)
Transfer rate: 98661.39 [Kbytes/sec] received
NGINXのベンチマークはこちらウェブ
内部 => @NGINX[HTTP] => @VARNISH => @APACHE:
Concurrency Level: 10
Time taken for tests: 0.082 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1001
Keep-Alive requests: 1000
Total transferred: 382382 bytes
HTML transferred: 184184 bytes
Requests per second: 12137.98 [#/sec] (mean)
Time per request: 0.824 [ms] (mean)
Time per request: 0.082 [ms] (mean, across all concurrent requests)
Transfer rate: 4532.57 [Kbytes/sec] received
NGINXのベンチマークはこちら翻訳
内部 => @NGINX[HTTPS=>HTTP] => @VARNISH => @APACHE:
Concurrency Level: 10
Time taken for tests: 7.029 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Keep-Alive requests: 0
Total transferred: 663000 bytes
HTML transferred: 401000 bytes
Requests per second: 142.27 [#/sec] (mean)
Time per request: 70.288 [ms] (mean)
Time per request: 7.029 [ms] (mean, across all concurrent requests)
Transfer rate: 92.12 [Kbytes/sec] received
答え1
まあ、あなたが提供した（または提供しなかった）情報から推測することしかできません。しかし、インスタンスタイプ（t2はバースト可能なチケットベースのパフォーマンスを持ち、チケットがなくなるとコアの約20％を取得します。ベンチマークを行うのに適したインスタンスではありません）とabテストでの使用（ちなみに、「ABテスト」と書いた場合、最初に思い浮かぶのはこれ) あなたのパフォーマンスはほぼ予想通りだったと思います。
SSL または TLS セッションを開始するとき、最もパフォーマンスを消費するタスクはデータの暗号化/復号化ではなく、キーの交換です。SSLabセッション キャッシュを使用しないため、接続ごとにキー交換を実行する必要があります。
実際に使用される暗号/kex/認証スイートによっては (出力が提供されていないため不明ab)、CPU にかなりの負荷がかかる可能性があります。また、両端が同じマシン上にあるため、接続ごとに CPU 要件が 2 倍になります (単純化されていますが、ここでは十分です)。
実際の使用では、キープアライブを使用するとパフォーマンスが向上する可能性があります (クライアントによって異なりますが、通常のブラウザではこれが使用されます。試してみてくださいab -k)。また、おっしゃった SSL セッション キャッシュを使用するとパフォーマンスが向上します (これもクライアントによって異なりますが、通常のブラウザではサポートされています)。
パフォーマンスを向上させる方法は他にもいくつかあります。もちろん、より優れたハードウェアを入手することもできます。キー サイズを最適化できます (アプリに必要な保護レベルによって異なります)。キーが小さいほど、通常はコストが安くなります。別のマシンでテストすると、明らかなパフォーマンスが向上する場合もあれば、向上しない場合もあります。また、異なる OpenSSL ビルドや異なる SSL ライブラリを入手することでも、パフォーマンスが向上する可能性があります。
参考までに、この紙Intel によるものです。高度に最適化されたマシン (および最適化されたソフトウェア) でパフォーマンスを比較しています。使用可能な計算能力は Intel の 1/30 以下 (チケットが不足している場合は 1/150 程度) であると考えてください。
ただし、高性能 SSL が必要な場合は、すでに EC2 を使用しているため、Amazon ELB を使用して SSL ターミネーションを実行することを検討する価値があるかもしれません。
編集: 例えばアパッチ JMeterSSL コンテキスト キャッシュを使用します。httperfも同様です。特に JMeter は、現実に近い負荷をシミュレートするのに優れていると思います。ただし、この場合は httperf のセッション キャッシュ方式が最適である可能性があります。
違いが見られないのは、-kまだ使用されていないためかもしれません。同時実行設定に依存し、(少なくとも私のマシンでは) URL にも依存しているようです。URL で複数の IP を指すドメイン名を使用する場合、キープアライブは使用されません (理由は聞かないでください)。
大規模かどうかの認識次第ですが、この比較的小さなインスタンスでは、バースト時に 1 秒あたり約 500 を超える接続が発生することはなく、持続的には 250 cps を超えることはないと予想しています。
varnish プレーンテキスト http と nginx ssl を比較するのは、梨とリンゴを比較するようなものです。 あるいは、ハードウェア要件の点では、ブルーベリーとスイカを比較するようなものです。
もう一度参考までに（Keep-Alive requests: 100線に注目してください）。
それなし-k
Concurrency Level: 1
Time taken for tests: 0.431 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 399300 bytes
HTML transferred: 381200 bytes
Requests per second: 232.26 [#/sec] (mean)
Time per request: 4.305 [ms] (mean)
Time per request: 4.305 [ms] (mean, across all concurrent requests)
Transfer rate: 905.69 [Kbytes/sec] received
と-k
Concurrency Level: 1
Time taken for tests: 0.131 seconds
Complete requests: 100
Failed requests: 0
Keep-Alive requests: 100
Total transferred: 402892 bytes
HTML transferred: 381200 bytes
Requests per second: 762.11 [#/sec] (mean)
Time per request: 1.312 [ms] (mean)
Time per request: 1.312 [ms] (mean, across all concurrent requests)
Transfer rate: 2998.53 [Kbytes/sec] received
編集2: メモリから直接コンテンツを提供することは (それが Varnish が行っていることです)、非常に簡単だということを理解する必要があります。ヘッダーを解析し、メモリ内のコンテンツを見つけて、それを吐き出します。そして、Varnish はこれに優れています。
暗号化された接続を確立するのはまったく別のレベルです。したがって、nginx を追加すると、SSL ハンドシェイク (キー交換、認証) と暗号化を行う必要があり、これにはさらに多くのリソースが必要になります。次に、ヘッダーを解析します。次に、Varnish への別の TCP 接続を作成する必要があります。
繰り返しになりますが、前述のインテルの論文、28 個のコアがあり、OpenSSL を少し調整して 38k HTTPS cps (Varnish のパフォーマンスより少し高い) を実現しています。コアの約 1/5 しかなく、仮想の隣人の影響を受けます。
たとえば、t2.small インスタンスは、1 時間あたり 12 CPU クレジットの割合で継続的にクレジットを受け取ります。この機能は、CPU コアの 20% に相当するベースライン パフォーマンスを提供します。
そしてまた紙nginx 自身から:
結果の概要 単一の仮想化された Intel コアは、通常、最新の暗号化方式を使用して、1 秒あたり最大 350 回の完全な 2048 ビット SSL ハンドシェイク操作を実行できます。これは、1 秒あたりコアあたり数百人の新規サービス ユーザーに相当することになります。