Webパフォーマンスについて

Webパフォーマンスについて記事を書いています。パフォーマンス管理は、品質管理です。ですから計測データを元に記事を書いてます。一緒に「品質の守護者」になりましょう!

HTTP/1.1とHTTP/2を比較する ― 第二回 ロリポップさんの検証サイト編

ロリポップさんで、HTTP/1.1とHTTP/2の比較サイトを立ち上げられていたので、計測して比較しました。

lolipop.jp

計測対象サイト

計測条件

  • 日本の帯域保証型(100Mbps)光回線を使用 NTT KDDI
  • 計測ブラウザ … Chrome53
  • 計測頻度 … 15分に1回
  • 計測期間 … 4月12日~5月9日の29日間
  • 計測ツール … Catchpoint

Catchpointを知らない方のために説明しますと、CatchpointはWebサイトのパフォーマンスを24時間365日定常監視・計測するためのサービスを提供している企業です。 f:id:takehora:20160614110855p:plain Googleの品質保証担当Vice PresidentだったMedhi Daoudiが2010年に立ち上げた企業で、現在、GoogleMicrosoftなどのテクノロジー企業、AkamaiやFastly、MaxCDNなどのCDN各社、Verizonなどの通信企業など、数多くの企業が利用しているサービスです。

ちょっと宣伝させて頂くと、現在、日本については私の会社Spelldataで販売しております。

計測結果

ダウンロード時間

f:id:takehora:20170509112828p:plain
1日単位での75パーセンタイルでの折れ線グラフ

KDDIでの計測データの統計要約
サイト平均最小25パーセンタイル50パーセンタイル75パーセンタイル最大値n
https://http1-1-contents.com1,495.501,0341,3401,3991,4927,2002,550
https://http2-contents.com1,370.087831,2241,3101,38919,6882,551
NTTでの計測データの統計要約
サイト平均最小25パーセンタイル50パーセンタイル75パーセンタイル最大値n
https://http1-1-contents.com1,727.344131,5371,6381,7655,4392,541
https://http2-contents.com1,700.412931,5341,6571,7859,3752,548

まずは、ダウンロード時間です。 まず、ダウンロード時間の定義ですが、HTTP/1.1もしくはHTTP/2の通信が途絶えてから2秒経過したところでダウンロードの完了と見做し、2秒マイナスした値となります。

商用計測サービスでは一般的なダウンロード時間の検出方法です。

グラフは、1日毎の75パーセンタイル値で生成しています。 何故、75パーセンタイルなのでしょうか?

表の最大値を見て下さい。 75パーセンタイル値に比べて最大値(100パーセンタイル)は、極端に遅延しています。 インターネットの中では、日々、様々な状況が発生しています。この影響によって遅延が生じます。 また、この計測対象自体は複数のホスト(Third Party)からファイルを取得しているため、それぞれのThird Partyの負荷状況によってパフォーマンスが遅延します。 結果として、全体の25%ぐらいは、どうしても、全体の他の値より遅延した集合となるのです。

これを考慮せずに平均してしまうと、表の平均値のように、最小と最大の情報が消えてしまい、実際の分布の把握が難しくなってしまいます。

平均値は、分布が左右対称の場合には一つの目安として有効ですが、このような非対称型の分布では平均値は役に立たないので注意が必要です。 統計学では、よく「平均値の罠」と言います。

さて、このデータを見ると、KDDIにおいては、HTTP/2の方が高速であり、NTTにおいてはHTTP/1.1の方が勝っているようです。 しかし、その勝り具合というのも微妙です。 累積分布関数でグラフにします。

f:id:takehora:20170625004154p:plain
ISP別ダウンロード時間の累積分布関数

このグラフは、横軸がパーセンタイル値、縦軸がダウンロード時間(ミリ秒)です。 このグラフで、何パーセントの確率で、何秒でダウンロードが終わるのかが、計測値のデータを元に判別できます。

これを見ると、大して差は無いのだと分かります。

層別に分析する

これらのダウンロード時間は、対象ページを構成する複数のホストからのファイルの配信のダウンロード時間の合算値になっています。 従って、これをホスト単位で見る必要があります。

  • ajax.googleapis.com
  • cdnjs.cloudflare.com
  • http1-1-contents.comもしくはhttp2-contens.com
  • lolipop.jp

統計学では、このようにある特徴によって、いくつかのグループに分けることを「層別化」と言います。 品質のばらつきを分析する観点では「分散の分解」とも言います。

KDDIの分析

まずは、KDDIのデータを分析してみましょう。

f:id:takehora:20170509122204p:plain
http1-1-contents.comのKDDIでの1日単位での75パーセンタイル値

これを15分単位での最大値でグラフ化すると、こうなります。

f:id:takehora:20170509122625p:plain
http1-1-contents.comのKDDIでの15分単位での最大値

すると一気にグラフの様相が変わりましたね。 1日単位のグラフは全体の傾向を調べるために、15分単位での最大値はパフォーマンスのサージ(突発的な遅延や負荷)の発生度合いを 見るために使います。

これだと、視覚に惑わされてしまうため、100ms単位の区間のダウンロード時間で棒グラフにしてみます。

f:id:takehora:20170509123816p:plain
http1-1-contents.comのホスト単位でのダウンロード時間の分布

このように見ると、http1-1-contents.com本体のHTTP/1.1の配信は、最頻値が200~300msであることが分かります。

次にHTTP/2です。

f:id:takehora:20170509124922p:plain
http2-contents.comのKDDIでの1日単位での75パーセンタイル値

f:id:takehora:20170509125138p:plain
http2-contents.comのKDDIでの15分単位での最大値

f:id:takehora:20170509125223p:plain
http2-contents.comのKDDIでのホスト単位でのダウンロード時間の分布

http-2-contents.com本体のHTTP/2の配信は、最頻値が600~700ms、最速でも400~500msであることが分かります。 分布もHTTP/1.1よりなだらかな山を形成しており、配信品質のばらつきが大きいことを示しています。

NTTの分析

次に、NTTのデータを分析してみましょう。

f:id:takehora:20170509130156p:plain
http1-1-contents.comのNTTでの1日単位での75パーセンタイル値

f:id:takehora:20170509130418p:plain
http1-1-contents.comのNTTでの15分単位での最大値

f:id:takehora:20170509130620p:plain
http1-1-contents.comのホスト単位でのダウンロード時間の分布

KDDIと違い、CloudFlareの配信が、NTTでは遅いことが分かります。 これが、KDDIよりも遅延している原因だったのです。

http-1-1-contents.com本体のHTTP/1.1の配信は、KDDIと同様に200~300msが最頻値であることが分かります。

次にHTTP/2です。

f:id:takehora:20170509131201p:plain
http2-contents.comのNTTでの1日単位での75パーセンタイル値

f:id:takehora:20170509131319p:plain
http2-contents.comのNTTでの15分単位での最大値

f:id:takehora:20170509131737p:plain
http2-contents.comのNTTでのホスト単位でのダウンロード時間の分布

http-2-contents.com本体のHTTP/2の配信は、最頻値が900~1,000ms、400~500msでの配信は2,541回のデータ中、12回しか観測されていません。 KDDIよりも更にHTTP/2の方が遅いことを示しています。

表示に関する指標 ― Render StartとDocument Complete

ダウンロードについては、HTTP/1.1の方が遥かにHTTP/2より速い事が分かりました。

しかし、重要なのは、表示速度です。 そこで、表示速度に関する指標である、Render StartとDocument Completeの値を見ていきます。

Render Start

f:id:takehora:20170509132854p:plain
Render StartのISP毎の15分単位での75パーセンタイル値

f:id:takehora:20170509154917p:plain
Render StartのISP毎の分布

Render Startについては、KDDIでもNTTでもHTTP/1.1の方が速いことが分かります。

これを累積分布関数のグラフにします。

f:id:takehora:20170625004602p:plain
Render StartのISP別累積分布関数

このグラフを見ても、若干HTTP/2の方が表示開始が遅いのが分かりますが、顕著な差ではないです。

Document Complete

f:id:takehora:20170509154559p:plain
Document CompleteのISP毎の15分単位での75パーセンタイル値

f:id:takehora:20170509154810p:plain
Document CompleteのISP毎の分布

Document Completeについては、HTTP/2の方がHTTP/1.1より僅かながらも速いことが分かります。

しかし、これも累積分布関数を見れば、大した差ではないと分かります。 KDDIでは差が出ていますが、NTTではほぼ同じです。

f:id:takehora:20170625004931p:plain
Document CompleteのISP別累積分布関数

結論

HTTP/1.1とHTTP/2の表示速度には、この検証サイトを計測した結果、有意差は無いです。

注意点

ご自身で検証される場合

もし、皆さんが、Chromeの開発者ツールなどで確認されるのであれば、以下の点に注意して下さい。

  • 必ずシークレットウィンドウで行う … 拡張機能などの影響を排除するためです。
  • 必ず一回読み込むごとに、シークレットウィンドウを立ち上げ直す … シークレットウィンドウであっても、キャシュが効いてしまい、リロードすると速い値が出ます。