静的Webページパフォーマンス比較: AWS S3 vs Apache vs nginx Part1

1秒を切るために

自社サイト(http://spelldata.co.jp)は、AWSのS3上に展開しています。
この自社サイトの計測値を見ていて、1秒を切れない計測点が現れているのが気になりました。

とあるお客様のサイトの高速化を行って、nginx+Wordpressで1秒を切るまでチューニングをしました。
それと比較して、静的なHTMLしか置いていないS3で1秒を切れない事があるのはどうかなと考えました。
この際、Apacheとnginxのサーバも立ち上げて、速度比較をしてみようと思い立ちました。

実験計画

比較対象

自社サイトコンテンツのトップページを計測して比較します。

この手の比較をする際に、負荷を徐々にかけて性能の変化を比較される事が多いのです。素の状態(負荷がかかっていない状態)で、どれだけの性能差があるのかを見るのは、基本性能を知るために欠かせないステップです。ですので、今回は、負荷はかけていません。

もう一つ、今回の比較では、同じ内容のコンテンツをアップロードして、トップページを1回閲覧するという方法で計測します。これも、性能比較で、JavaScriptで100回処理したとか、画像を100個読み込んだといったテストをされることがあります。そういうテストに意味が無いわけではないのですが、実際に運用するコンテンツや、CMSを使ってテストされる方が、現実に即した結果が得られると思います。

比較するシステム

• AWS(Amazon Web Service) S3(Simple Storage Service)
• AWS EC2 m1.medium + Slackware-current(64bit) + Apache 2.4.10
• AWS EC2 m1.medium + Slackware-current(64bit) + nginx 1.6.2

m1.mediumは、「一般的な目的 - 前の世代」のインスタンスです。1時間0.0101ドル(1ドル120円換算で1.212円)で使えます。

スペックとしては、以下の通りです。

• ディスク - EBS(Elastic Block Store)
• vCPU - 1
• メモリ - 3.75GB

計測計画

計測期間は1～2日で、以下の3つのブラウザで計測します。

• IE9.0 … SPDY Off
• Firefox 14.0.1 … SPDY On
• Chrome/31.0.1650.63 … SPDY On

計測のプラットフォームとしては、毎度ながら、Keynote Systemsのデスクトップ計測Web Monitoring TxPを利用しています。
(日本では、私の会社Spelldataがサービス提供しております。)

計測で使う回線は、NTTとKDDIの光回線です。

計測頻度は、1時間に1回です。

計測値を自社サーバのみと、サードパーティーコンテンツに分ける

弊社のhttp://spelldata.co.jpのコンテンツは、

• Google Analytics
• Piwik(自社別ドメイン運用)

と2つのアクセス解析のスクリプトが入っています。

このような自分のドメイン以外のコンテンツを「サードパーティーコンテンツ」と呼びます。

普通に計測すると、自社サーバコンテンツの計測値とサードパーティコンテンツの計測値が混ざってしまいます。

IEで計測した結果のWaterfall図

今回は、純粋にプラットフォーム別の速度比較をしたいので、データを分けるように設定します。

Keynoteの機能でVirtual Pageというのがあります。これは、計測値の内、特定のドメインの計測値だけにしたり、逆に特定のドメインの計測値だけを除いたりすることができるというものです。

計測スクリプト作成ツールKITEでの設定画面

 この設定で計測した結果が、下のWaterfall図で、自社ドメインからのみ配信されたオブジェクトの計測のみになっています。

IEで計測した結果のWaterfall図(自社ドメインのみに絞った計測結果)

「終了」の定義

計測において、何を以って「終了」とするかは、とても重要です。それ次第で、計測値は大きく変わります。通常、私は、HTTP/HTTPSの通信が3秒以上途絶えたら、「終了」と認識させるようにしています。これで、Ajaxのような、OnLoad後の非同期通信も確実に計測が可能になります。

計測結果

Internet Explorer

IE9で計測した全てのダウンロード計測値の散布図

水色がS3、オレンジがApache、青がnginxになります。このデータを見るとApacheのばらつきと、S3のばらつきが目立ちます。

サードパーティコンテンツのデータを抜いたデータを見ましょう。

IE9で計測した自社サーバのみのダウンロード計測値の散布図

このデータを見ると、縦軸の目盛りが変わって、最大で2.5秒になっています。殆どの計測値は0.5秒以下です。

このデータを「標本の分布」図とヒストグラムで見ます。

IE9で計測した自社サーバのみのダウンロード計測値の分布図とヒストグラム

緑がS3、オレンジがApache、ピンクがngnixです。分布図で見ると、S3のパフォーマンスのばらつき具合がわかります。また、ngnixの方がApacheよりばらつきが少なく、パフォーマンスが良いのがわかります。

Firefox

Firefox14で計測した全てのダウンロード計測値の散布図

水色がS3、オレンジがApache、青がngnixです。IEよりもばらつきが出ているのがわかります。

これを自社サーバのみのパフォーマンスで見てみましょう。

Firefox14で計測した自社サーバのみのダウンロード計測値の散布図(最大値5秒でグラフ生成)

このグラフで見ると、IEと同じように、殆どの計測値が0.5秒以下で、S3のばらつきが目立ちます。Apacheとnginxのばらつきは同程度です。

このデータを「標本の分布」図とヒストグラムで見ます。

Firefox14で計測した自社サーバのみのダウンロード計測値の分布図とヒストグラム

このグラフを見ると、Apacheとnginxの性能はほぼ互角という感じです。

Chrome

Chrome31で計測した全てのダウンロード計測値の散布図

水色がS3、オレンジがApache、青色がnginxです。S3とApacheのばらつきが目立ちますね。これを自社サーバのみにします。

Chrome31で計測した自社サーバのみのダウンロード計測値の散布図

このグラフで見てみると、全体的にIEやFirefoxと比べてばらつきが大きいというのが分かります。

Chrome31で計測した自社サーバのみのダウンロード計測値の分布図とヒストグラム

このデータを「標本の分布」図とヒストグラムで見ると、このようになります。緑がS3、オレンジがApache、ピンクがngnixです。ApachやnginxがS3より速いのは分かるのですが、全体的にはそれほど差が無い事が分かります。

箱ひげ図で、全てを比べてみる

自社サーバのオブジェクトのみの計測値について、一旦、折れ線グラフにしてみます。

平均値が出ていますが、全て1秒を切っています。これが平均値の怖い所です。平均されると、悪い数値の情報が消えてしまうのです。

さて、このデータをExportして、Rに取り込んでみます。

すると、以下のようなExcelのシートになります。個々の計測値(ダウンロード時間)が取り出せます。これをRに取り込みます。 

まずは、統計量を層別で見てみます。

                       mean      sd        IQR     0%    25%     50%    75%     100%     data:n
Apache - Chrome - KDDI 0.3507778 0.1382710 0.16775 0.182 0.24875 0.3155 0.41650 0.919     36
Apache - Chrome - NTT  0.5634722 0.4539345 0.40600 0.119 0.25700 0.4305 0.66300 1.979     36
Apache - FF - KDDI     0.2709459 0.1280696 0.04100 0.156 0.22200 0.2350 0.26300 0.936     37
Apache - FF - NTT      0.1859143 0.1337107 0.11200 0.069 0.10700 0.1450 0.21900 0.712     35
Apache - IE - KDDI     0.3422703 0.3593682 0.05900 0.176 0.19000 0.2050 0.24900 1.705     37
Apache - IE - NTT      0.1371282 0.1937768 0.11650 0.037 0.04500 0.0630 0.16150 1.048     39
ngnix - Chrome - KDDI  0.4222222 0.2312363 0.16675 0.217 0.27550 0.3580 0.44225 1.295     36
ngnix - Chrome - NTT   0.4706842 0.3922779 0.41875 0.097 0.21950 0.3045 0.63825 1.895     38
ngnix - FF - KDDI      0.3198974 0.1354435 0.13100 0.173 0.23950 0.2820 0.37050 0.911     39
ngnix - FF - NTT       0.1912105 0.1910664 0.07600 0.076 0.10200 0.1305 0.17800 1.038     38
ngnix - IE - KDDI      0.2536750 0.1656596 0.09750 0.152 0.16875 0.1950 0.26625 1.036     40
ngnix - IE - NTT       0.1306571 0.1071656 0.09600 0.039 0.05900 0.0890 0.15500 0.499     35
S3 - Chrome - KDDI     0.6379189 0.2908783 0.45200 0.291 0.38100 0.5490 0.83300 1.247     37
S3 - Chrome - NTT      0.4265946 0.1949672 0.21100 0.195 0.28100 0.3810 0.49200 1.052     37
S3 - FF - KDDI         0.5371143 0.3195030 0.35900 0.247 0.32600 0.3510 0.68500 1.266     35
S3 - FF - NTT          0.3735152 0.1991972 0.15500 0.173 0.25400 0.2980 0.40900 1.031     33
S3 - IE - KDDI         0.6114324 0.4127385 0.36500 0.218 0.35900 0.4120 0.72400 1.829     37
S3 - IE - NTT          0.3100833 0.1231773 0.13175 0.165 0.23575 0.2555 0.36750 0.680     36

層別で、データを見るというのはとても大事です。上述のグラフでは、回線での違いについては考慮せずにデータを見てきました。しかし、異なる性格のものについては、分けて分析した方が良いです。ですから、NTTとKDDIについては、分けました。

箱ひげ図で比較する

普通に箱ひげ図を作ると、以下のようになります。

(箱ひげ図については、既に別の記事で一度解説しています。わからない方は、Googleで検索して学んで下さい。2012年から、高校1年の数Iで教わるようになっています。2014年度の大学入試センター試験でも、箱ひげ図が出ました。)

グラフ生成時に、オプションを付けないと、1Q-(IQRx1.5)より小さいもの、3Q+(IQRx1.5)より大きいものは、外れ値として○で表示されます。

この箱ひげ図を見ると、S3よりApacheやngnixの方が速いことが分かります。

S3、Apache、nginx、それぞれの箱ひげ図を比較すると、AWSは、NTTについてはスピードが速いものの、KDDIについては若干遅いということも分かります。

Apacheとnginxを比較すると、ブラウザによってはApacheが速いものもあれば、nginxの方が速いものもあり、優劣つけがたいです。

Q1-IQR×1.5、Q3+IQRx1.5を外れ値として扱わず、箱ひげ図を生成した場合

ここまでのまとめ

1時間に1回のアクセスの負荷程度では、Apacheとnginxの間に性能の差は見られませんでした。

この結果を、「そりゃそうさ、当たり前じゃないか。予想がつくじゃないか。」と思う方もいるかもしれません。しかし、予想と、実際の数字として持つということの間には、天と地の差があります。

Apacheとnginxの性能差は、ある一定の規模のアクセス数を超えたあたりから見えてくるのでしょう。それについては、いずれ、負荷テストを行ってみて検証したいと思います。

上記で見てきた「標本の分布」は、正規分布のベルカーブとは言えない形です。右に裾野が広い非対称型の形です。

世の中の「標本の分布」は、殆どがベルカーブにはなりません。しかし、「標本の分布」の平均(標本平均)を沢山集めると、これはベルカーブになります。これを「標本分布」と言います。

例えば、この計測を30日間続けて、毎日の平均値(標本平均)を30日分集計すれば、異なる分析結果が見えてくるかもしれません。

次回は、その点を検証してみたいと思います。

補足

ちなみに、全てのファイルのダウンロードにかかる時間(DNS Lookup、Initial Connection、First Byte Download、Content Downloadなどの成分)を使って、主成分分析をしてみたのですが、KDDIの方がNTTよりDNS Lookupで時間がかかっているということが分かりました。実際に、データを見てみると、確かに、KDDIの方が、NTTより平均して2倍、DNSの反応速度が遅いです。何故なのかは、分かりません…

KDDIのDNS Lookupにかかる時間 - 平均0.026秒

NTTのDNS Lookupにかかる時間 - 平均0.013秒