「超チューニング祭 ～ニコニコを超快適にしてみた～ in ニコニコ超会議３」の問題点
来る2014年4月26日(土)・27日(日)に、「ニコニコ超会議3」が開催され、その中で「超チューニング祭 ～ニコニコを超快適にしてみた～」が開催されるそうです。
これは、現行のスマートフォンサイトのTopページのソースファイルを競技者がチューニングして、速度やデザイン・UIの改善をして、速度と使い勝手を競うのだそうです。
「これは面白そうだ! 会場は家から近いし!」と思って参加するつもりでいましたが、事前調査で計測してみた結果、フロントエンドのチューニングでは速くならないことがわかったので、その内容について説明します。
(主催者の方にも、フロントエンドのチューニングでは速くならないという情報は伝えてあります。)
まずは、計測データ
まずは実際のトップページ(http://sp.nicovideo.jp)の計測データを見てみましょう。
計測は、NTT DoCoMoとSoftBankの3G回線で、1時間に1回の頻度で行いました。
使ったスマートフォンの仕様は、iPhone5S (iOS 7.0.1)になります。
これは、実際のハードウェアを使わずエミュレータを使っており、iPhone5S(iOS 7.0.1)のブラウザ挙動や仕様をエミュレートしており、ハードウェア仕様はエミュレートしていません。
何故、ハードウェア仕様(CPU、メモリなど)をエミュレートしていないかというと、ハードウェアの仕様も含めると、計測されるデータの数値を決定する変数が増えてしまうからです。
ハードウェアの仕様は含めないことで、計測データの数値に影響を与えるのは、携帯網の状況、サーバ側の状況、そしてコーディングの状況(HTMLやCSS、JavaScriptの書き方)の3つに集約できるからです。
これが、計測値をプロットした散布図になります。横軸が時間の推移、縦軸がパフォーマンス(ダウンロード時間)の秒数です。
このTopページですが、何を以って1ページの終わりと定義するかが重要です。この計測では、HTTP/HTTPS通信が2秒以上検知されなかった場合に、「終了」と定義して、そこまでの時間をプロットしています。
三種類の点があります。
- 緑の菱型の点は、何のエラーも検知されずに計測が終わったデータ
- 黄色い丸い点は、一部コンテンツエラーが検知されたデータ
- 赤い三角の点は、Timeout(120秒を超えた)になったデータ
を表わしています。
この図を見ることで、凡そのパフォーマンスパターンを見ることができます。
夜の23時から3時ぐらいまでパフォーマンスが悪化していく様子と朝6時から12時にかけてパフォーマンスが良くなっている様子がわかります。
このようなデータは、本当は最低でも一週間、できれば二週間分あると、日次パターンと週次パターンを的確に掴むことができます。
このデータを品質として見る場合には、ヒストグラムにします。
ヒストグラムにすると、このような図になります。横軸がパフォーマンスの秒数、縦軸がその秒数で計測された回数を表します。
これを見ると、速い時は速いですが、遅い時は限りなく遅いです。
この図のどこに着目するかというと、赤い枠で囲んだ箇所です。12秒以上、時間がかかっている部分に焦点を当てます。
仮に、ユーザーが12秒までは待てるとしましょう。
12秒以下で計測できた回数は、14+17=31回です。12秒以上かかっている計測の回数は30回です。
結果、歩留りとしては約50%になります。つまり2回に1回は、期待している性能を満たしていない配信であるという事になります。
(実際は、ユーザーが待てる秒数は、スマートフォンサイトで4～5秒と各種調査で言われていますが、ニコニコ動画は人気のあるサービスですから、ユーザーが我慢強いと想定して、その4秒の3倍にしてみました。)
遅延グループ1の詳細分析
ここから遅延の原因を分析していきます。最も遅い計測値のグループがあります。それを「遅延グループ1」と、ここでは名づけておきます。
遅延要因は、特に遅延しているデータを見ると、その特徴がよくわかります。上の図の赤枠で囲んだデータです。まずは、左から順に見て行きましょう。ちょっと、長い図になります。
左から一番目の計測点の詳細図～ウォーターフォール図
一番最初の部分で緑色の棒が伸びています。緑色は、DNSの名前解決にかかった時間を表わしています。実際の数値は、71.875秒です。HTMLファイルやCSS、JavaScriptといった構成ファイルのダウンロード自体は、100～600msで並列してダウンロードできています。
このデータから、どうもDNSが遅延要因として考えられることがわかります。しかし、これはたまたまそうだった、という事かもしれません。(統計では、外れ値と言います。)
そこで、他のデータも見ていって、頻発しているのか、たまたまなのかを判断していきます。
左から二番めの計測点の詳細図～ウォーターフォール図
途中、赤字が付いている箇所は、コンテンツエラーです。下の方で大きく二本、黄色というか黄土色の棒が伸びています。これは、ファイルの1バイト目が届いてから、ファイルの一番最後のお尻のバイトが届くまでの時間(Content Download Time)を指しています。
そして、この二つの遅延を引き起こしているのは、ニコニコ動画のサーバではなく、広告配信事業者(i-mobile.co.jp)のコンテンツです。
左から三番目の計測点の詳細図～ウォーターフォール図
途中、緑の棒がぐーんと伸びています。これは1番目と同じく、DNSの名前解決です。
何故、これだけの数のファイルが一度にDNSの名前解決で時間がかかっているかというと、並行ダウンロードであるからです。同じサーバに対して一気に複数のファイルをダウンロードしようとしているのですが、名前解決ができないために、それら全てのダウンロードが待たされているわけです。
左から四番目の計測点の詳細図～ウォーターフォール図
これは、一番下の方で緑の棒が伸びています。緑は、そう、DNSの名前解決。そして、この遅延しているコンテンツは、やはり広告配信事業者(i-mobile.co.jp)のコンテンツです。
左から五番目の計測点の詳細図～ウォーターフォール図
これは一番目と同じ現象ですね。sp.nicovideo.jpの名前解決に時間がかかり、全体のダウンロードが遅延しています。
このように見ていくと、どうもニコニコ動画のスマートフォンサイトのTopページの遅延要因は、
- DNSの名前解決
- サードパーティー(i-mobile.co.jp)
の二つであるらしいという事がわかります。
遅延グループ2の詳細分析～遅延要因の「頻度」を見る
しかし、この5つの計測は、「たまたま」かもしれません。そこで、他の計測値にも、この二つの要因が関わっているか、また他には要因が無いかを掘り下げて調査します。
ここで、2番めに遅いグループ「遅延グループ2」の詳細を調査します。
25秒より時間がかかっているパフォーマンス計測の値の群、赤枠で囲った部分です。
左から一番目の計測点の詳細図～ウォーターフォール図
こちらのデータを見ると、やはりDNSの名前解決に時間がかかっています。(27.797秒)
ですから、程度の差はあれ、DNSの名前解決の遅延が原因であることがわかります。
左から二番目の計測点の詳細図～ウォーターフォール図
この図を見ると、今までと違って、オレンジ色の部分が足を引っ張っているのがわかります。オレンジ色は、Initial Connection、つまりTCP/IPの3way handshakeにかかった時間です。
これで時間がかかっている場合は、ネットワーク機器に問題があることが考えられます。(性能が不足している、回線帯域、ネットワーク機器もしくはサーバのネットワーク層で処理できるキャパシティや帯域が不足している。)
もしくは、携帯網の中の通信に問題がある場合にも、このような遅延が見られます。
左から三番目の計測点の詳細図～ウォーターフォール図
これもDNSの名前解決ですね。
左から四番目～八番目の計測点の詳細図～ウォーターフォール図
他も全てDNSの名前解決の遅延が原因になっています。
左から四番目～八番目の計測についての詳細を以下の掲載します。
殆ど違いが見受けられませんね。
Initial Connection (TCP/IP 3way handshake)の遅延は携帯網が原因か、サーバ側が原因か?
遅延グループの左から二番目のデータでは、Initial Connection(TCP/IP 3way handshake)の遅延が見られました。
これが、携帯網の問題なのか、それともサーバサイドの問題なのかを切り分ける必要があります。
この切り分けのために、同じ計測の仕組みで、今度はLAN回線で計測してみます。
そうすれば、携帯網と違って、途中経路の問題が変数として絡んでくることがあまりなくなるので、明確に切り分けることができます。
こちらが、LAN(NTT光回線)を使った計測の散布図になります。
3G回線の詳細分析をしたように、LANでの計測でも遅延グループ1から見ていきます。
遅延グループ1の左から一番目の計測点の詳細図～ウォーターフォール図
これを見ると、オレンジの部分、Initial Connectionの遅延がはっきりと出ています。(9.017秒)
実際のコンテンツの配信ドメインは、smilevideo.jpです。
3GでのInitial Connectionの遅延では、nicovideo.jpもsmilevideo.jpも双方のドメイン配下のコンテンツについて、この症状が出ていました。つまり、サーバのネットワークカードとか、サーバの通信処理の問題ではなく、その手前にあるネットワーク機器に要因がありそうだとこれでわかります。
(同じサーバ上で、バーチャルホストを切って運用しているとか、同じ物理サーバ上でそれぞれのドメイン用に仮想マシンを運用しているというのでなければ、ですが)
遅延グループ1の左から二番目の計測点の詳細図～ウォーターフォール図
こちらについても、同様の結果が出ました。面白いことに、かかっている秒数もほぼ同じなのです。(9.016秒)
1番めのデータと、0.001秒しか違いません。
遅延グループ2の左から一番目の計測点の詳細図～ウォーターフォール図
こちらもInitial Connectionの遅延が出ています。面白いことに、3.011秒と遅延グループ1の約3分の1の値です。それは、遅延グループ2の他のグラフも同様なのです。
このように同一の数値が繰り返し出るのは、偶発的に起こりうることではないので、どうもネットワークの設定(もしくは仕様)が何かをしているようだとわかります。
また、Initial Connectionの4本の帯の後に、黄土色の帯が出ています。これは、Content Downloadです。3Gの遅延グループの2でも説明しましたが、ファイルの1バイト目が届いてから、ファイルの一番最後のお尻のバイトが届くまでの時間です。これがLAN回線の計測で出る場合は、ディスクアクセスに問題があることが多いです。
しかし、このContent Downloadも3.011秒です。おかしいですね。
遅延グループ2の左から二番目の計測点の詳細図～ウォーターフォール図
これも3秒のInitial Connectionの遅延が出ていますが、冒頭で出て、その後、また出ているというパターンです。こちらも、それぞれ3.011秒です。
遅延グループ2の左から三番目の計測点の詳細図～ウォーターフォール図
こちらも同様に、3.011秒のInitial Connectionの遅延です。
遅延グループ2の左から四番目の計測点の詳細図～ウォーターフォール図
こちらは、Content Downloadの遅延です。3.011秒です。
こうやって見てみると、サーバ側でランダムに意図的に遅延させるアルゴリズムが走っていると思われます。何故かというと、通常、Content Downloadの時間は、ファイルサイズに依存するため、きっかり3.011秒という数値になるのはあり得ないからです。このランダムに入る遅延は、3秒か9秒か、という選択らしいです。
データを基に改善することの重要性
このように見ていくと、大きな遅延要因は3つあることを発見できました。
- DNSの名前解決
- サードパーティーコンテンツ(i-mobile.jp)
- サーバ側で入れているランダムな遅延らしきもの
これらは、果たして、フロントエンドのチューニングで改善できるでしょうか?
できませんよね。
HTMLの書き方とか、JavaScriptの書き方とか、画像サイズの処理で解決できません。
DNSの名前解決、Initial ConnectionとContent Downloadで現れる遅延は、インフラの問題です。サードパーティーコンテンツも、外すという以外は手の着けようがありません。これは、どうしてここの広告配信を使うと決めたかという、ビジネスマターです。
私が、ここで言いたいのは、この企画自体ではなく、「企画するにあたって、まずは実際に計測してみて現状を分析したのかどうか?」という点なのです。
競技として行うのであれば、また、競技の結果、優秀な成果物が本番環境に適用されるというのであれば、「フロントエンド処理に問題がある」という事を担保しなければいけません。これは主催者の義務であるはずです。
特に、今回のような企画であれば、参加者からすれば、自分たちの成果物が、その後、サービス利用において、よりキビキビと動くであろうことを期待しますよね。
一生懸命やっても、実際にはそれほど結果に結びつかないよ、というのでは、この企画の意義が失われるでしょう。
競技としてのルール上の問題点
昨日公開された基本ルールを読んで問題だと思ったのは、計測に関する規定です。
- 計測の頻度が明記されていない(計測頻度が多ければ多い程、真の値に近づく。1～3回の計測頻度では、サンプル数としては足りない。)
- 計測環境の定義、その環境がどの程度保持できるかの担保
- 計測機器が共有されない(競技者と審判が同じモノサシを持てないのでは、競技として成り立ちません)
- 何を計測するのか(表示速度なのか?ダウンロード時間なのか?表示速度の場合は、具体的にはどのように計測するのか?ダウンロードの場合は、ページの終わりをどのように定義するのか?)
これらについて、是非、改善されることをお勧めいたします。
その後の状況変化について
パフォーマンス上のボトルネックがフロントエンド処理に起因しない件については、既にドワンゴ、並びに主催者の方に連絡をしてあります。
昨日(16日)の午後に、DNSのTTLが5分から1日に変更されています。それに伴い、DNSの遅延は、減少しています。
(赤枠の部分が変更後のDNSのパフォーマンス状況。)
何故、DNSのTTLが短いことが問題かというと、DNSという仕組みは分散処理システムであり、処理するサーバが分散されていれば、サーバの能力が余程劣らなければ、負荷の問題は発生しません。
しかし、携帯網の場合は、日本であれば、NTT DoCoMo、SoftBank、KDDIの三社のDNSに集約されます。もし、5分のTTLで設定すれば、5分毎にドメイン名とIPアドレスを紐付けたマッピングテーブルのキャッシュが消えるので、数万人単位でDNSの名前解決の問い合わせが来ます。
今、どのWebサイトもTTLを短くしているので、それがダイレクトにキャリアのDNSの負荷に繋がっているのです。
ですから、DNSのTTLを短く設定すれば、それだけ負荷の高いキャリアのDNSへ頻繁にアクセスしなければいけなくなり、それが更に負荷を増大させるのです。
こちらの記事が参考になるでしょう。
(スマートフォンのDNSの設定を別の会社のDNSサーバのIPに決め打ちにすると速くなるというTipsが一時期流行りましたよね。それは、上記のような原因があるからです。)
今回の企画はドワンゴが行っているわけではなく、別の企業の方がやっているので、残りの設定を変更できるのかどうかはわかりません。
競技計測用のサーバを別途用意して、そこのアップロードするということなので、もしかすれば、残りのボトルネックについては競技中は回避できるかもしれません。
いずれにせよ、主催者としての現状分析は、事前情報として競技者に通知されるべきでしょう。
私は、色々と考えた末に参加しないと決めましたが、このイベント自体は素晴らしいと思うし、成功して欲しいと思います。また、このイベントに参加される方のご健闘をお祈りしています。
このイベントが成功裏に終わって欲しいと思うので、問題点を指摘し、それを裏付けるデータを公開しました。
何らかの形で、この記事が貢献できれば幸いです。
追記(2014/4/17 17:20)
Initial Connectionの3秒・9秒の件
こちら、多くの方から、3way handshakeのSYNの再送待ち時間ではないか?というご指摘を頂きました。 ありがとうございます。
私も、最初それを疑ったのですが、記事中に書いてある通り、これがInitial Connectionだけでなく、一部Content Downloadにも現れているので判断しかねています。
「実は、FINも同じなんだよ」という情報をお持ちでしたら、今後の勉強のためにご教授頂けると幸いです。
考えられる事項として、「接続先のサーバがさらに別サーバに接続していて、そこでSYN再送が発生しているのではないか」という情報を頂きました。DNSを見ている限りではCDNを使っていないようなので、その可能性を考えていませんでした。ありがとうございます。
DNSのTTLの件
先程、TTLを確認したら、再び5分に戻っていました。運用上、致し方ないのかもしれません。
