軽量な静的コンテンツ配信におけるHTTP/2とSPDYのWebサーバの性能を見てみよう

既存のHTTPやWebサーバの技術を見ているものとして、新しい技術も調査しておかないといけないなということで、今日はHTTP/2とSPDYでおしゃべり可能なWebサーバの性能を見てみたいと思います。

HTTP/2の実装としては、tatsuhiro-tさんのC言語実装ライブラリであるnghttp2に注目しており、今日はそのライブラリを使って実装されているWebサーバnghttpdを動かし、SPDY/3.1で動作しているnginxとの性能比較をしました。HTTP/2やSPDY/3.1はもちろんクライアント側も既存のベンチマークツールではおしゃべりできないので、nghttp2で実装されているh2loadを使用しました。weighttpと使い方が似ているため個人的には非常に使いやすいです。

tatsuhiro-tさんによって先行してベンチマークが公開されていますが、僕自身も自分の環境で色々と実験したり実装を弄っているので、実際に自分の環境を構築して試しました。

nghttp2の導入

今回は最初なのでnghttp2の導入を簡単に紹介します。基本的にはnghttp2のGitHubにドキュメントがあるので、それをみてインストールすれば問題ないでしょう。今回は評価対象にSPDYが含まれているのでh2loadをビルドする際にSPDYライブラリのC実装であるspdylayが必要になりますので、それもビルドしましょう。今回はprefixは/usrにして、パスの通った環境にバイナリを全ていれてしまっています。

git clone https://github.com/tatsuhiro-t/spdylay.git
cd spdylay
autoreconf -i
automake
autoconf
./configure --prefix=/usr
make
make install
cd ..
git clone https://github.com/tatsuhiro-t/nghttp2.git
cd nghttp2
autoreconf -i
automake
autoconf
./configure --with-spdylay LIBSPDYLAY_CFLAGS="-I/usr/include/ -L/usr/lib64" LIBSPDYLAY_LIBS=-lspdylay --prefix=/usr
make
make install

これで今回必要なバイナリは準備できました。では実際にHTTP/2なサーバnghttpdを起動させます。今回はHTTP/2もTLS有りで起動させてSPDYとできるだけ近い条件で評価を行いたいと思います。

nghttpd -n 2 -d `pwd` 8080 ssl/server.key ssl/server.crt

とりあえず、dオプションによりカレントディレクトリをドキュメントルートにしました。そして、今回の検証環境はコア2つのメモリ8GBのVM上で動くFedora19ですので、nオプションによりworkerスレッドを2つ起動させました。後はListenするポートを8080、private keyとcertficateファイルを指定します。

SPDY/3.1で動くnginxの導入

nginxは皆さんご存知だと思うので導入は大部分省略しますが、nginx-1.5.11をダウンロードし以下のビルドオプションでビルドしました。

./configure ¥
--prefix=/usr/local/nginx-1.5.11 ¥
--with-http_ssl_module ¥
--with-http_spdy_module ¥
--with-http_gunzip_module ¥
--with-http_gzip_static_module ¥

インストール後は以下のような設定ファイルを用意しました。もっと性能が出る設定があるかもしれませんが、今回はこの設定を前提に比較しようと思います。

worker_processes 2;

events {
worker_connections 1024;
accept_mutex_delay 100ms;
}

http {
include mime.types;
default_type application/octet-stream;

sendfile on;
tcp_nopush on;
access_log off;

# SPDYテスト時はgzip関連はコメントアウト
gzip on;
gzip_comp_level 9;

keepalive_requests 10000;
keepalive_timeout 65;

server {
listen 81;
server_name localhost;

location / {
root html;
index index.html index.htm;
}

error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}

server {
listen 8081 ssl spdy;
server_name localhost;

spdy_headers_comp 9;

ssl_certificate ssl/server.crt;
ssl_certificate_key ssl/server.key;

ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;

ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

location / {
root html;
index index.html index.htm;
}
}
}

h2loadとweighttpによるベンチマーク

まずは一旦、nginxをSPDYでない状態（上記のポート81でのListen設定）で起動させてweighttpでベンチマークを書けてみます。テスト環境はIntel i7-4770K CPU @ 3.50GHzのコア2つとメモリ8GBのFedora19がVMwareのVM上で動いています。また、今回はヘッダ圧縮や並列ストリームの効果を見たいので、ヘッダの量の影響を大きくするためにContent-Lengthが21byte程度の軽量な静的コンテンツをリクエスト対象にしました。

HTTP/1.1のnginx

まずは、SPDYでないnginxに対して同時接続数100、総接続数10万のkeepalive有りでベンチマークをかけます。

$ weighttp -k -c 100 -n 100000 http://127.0.0.1:81/index.html
weighttp - a lightweight and simple webserver benchmarking tool

starting benchmark...
spawning thread #1: 100 concurrent requests, 100000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 2 sec, 255 millisec and 990 microsec, 44326 req/s, 11124 kbyte/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 25700000 bytes total, 23600000 bytes http, 2100000 bytes data

44326 request/secとなりました。このテスト環境上は非常に速いです。

SPDY/3.1のnginx

続いて、SPDY/3.1なnginxに対してh2loadでベンチマークをかけます。同時接続数100、総接続数10万で、SPDYやHTTP/2は各セッション上で処理する並行ストリームの数をクライアントから指定できるので、今回は同時接続数に合わせて並行ストリーム数を100にしました。このストリーム数を変化させる事で大きく性能が上下する事は言うまでもありません。

$ h2load -n100000 -c100 -m100 https://127.0.0.1:8081/index.html
starting benchmark...
spawning thread #0: 100 concurrent clients, 100000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 1 sec, 293 millisec and 127 microsec, 77331 req/s, 2727 kbytes/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 5215400 bytes total, 1511000 bytes headers, 2100000 bytes data

77331 request/secとなりました。keepalive有りのHTTP/1.1の静的配信と比べて約2倍の性能がでています。また注目すべきはベンチマークの最終行の転送量ですが、HTTP/1.1のリクエスト時のヘッダー転送量が23600000bytesなのに対し、SPDY/3.1ではヘッダ圧縮の効果により1511000bytesとヘッダの転送量が15分の1程度になっています。

HTTP/2かつTLSのnghttpd

では最後に、HTTP/2かつTLSなnghttpdに対してh2loadでベンチマークを書けてみます。ベンチマークのパラメータはSPDY時と同様です。

HTTP/2のリクエストなので、一旦ここでレスポンスまでの流れを確認しましょう。ザーッと書きます。

まずは、現状はNPNでh2-10が返ってくるはずです。また、NPN negotiated後にクライアントからSETTINGSフレームで並行ストリームの数やウィンドウサイズの数を送り、続いてリクエストのHEADERSフレームを送ります。その後、サーバ側からクライアントで指定した設定に関するSETTINGSフレームが返って来て、クライアントからACKとして再度SETTINGSフレームを送り、サーバからACKでSETTINGSフレームが返って来ます。そして、サーバからレスポンスのHEADERSフレームが返ってきた後、続いてコンテンツのデータがDATAフレームとして返って来ます。サーバから送るべきデータの送信が完了したら、続いてサーバからEND_STREAMがDATAフレームとして送られてきます。それを受けたクライアントはGOAWAYフレームを送信して接続を完了します。

では、ベンチマークの結果を見てみましょう。

$ h2load -n100000 -c100 -m100 https://127.0.0.1:8080/index.html
starting benchmark...
spawning thread #0: 100 concurrent clients, 100000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 0 sec, 797 millisec and 384 microsec, 125410 req/s, 3094 kbytes/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 4928985 bytes total, 426885 bytes headers, 2100000 bytes data

125410 request/secとnginxのSPDYやHTTP/1.1と比較して、非常に速い事がわかります。というよりも、この検証環境の静的ファイル配信でこんな値を見たことが無いレベルです。ヘッダーのサイズはSPDYの1511000bytesよりも更に少なくSPDYのヘッダの3分の1の426885bytesとなっており、HTTP/1.1のヘッダの転送量から見ると45分の1になりました。この1セッション時に使用する並列ストリームを100から減らしていくと性能がどんどん劣化し、並列ストリーム数を1つにすると大体nginxのHTTP/1.1程度の性能になることも確認しました。このセッション単位の並列ストリームのアーキテクチャとヘッダ圧縮が、軽量な静的コンテンツ配信の性能に大きく貢献している事が分かります。

最後に上記のベンチマーク結果を表にまとめておきます。

	nginx HTTP/1.1	nginx SPDY/3.1	nghttpd HTTP/2 + TLS
Request/sec	44326	77331	125410
Headers Traffic(kbytes)	23600	1511	426.885

まとめ

というように、今回はHTTPプロトコルの新しい技術であるHTTP/2やSPDY/3.1の軽量な静的ファイル配信の性能を確認してみました。並列ストリームやヘッダ圧縮、データ転送のバイナリ化によって、このようなベンチマーク環境及び条件においては性能が大きく向上している事がわかりました。また、条件の違いでプロトコルの有利不利が生じると思うので、様々なコンテンツ配信の特徴に合わせた設計は今後も必要だと思います。

それにしても、HTTPの今後が楽しみです。