Firebugを使ってTwitterのパフォーマンス解析をしてみた
Webサイトの管理者や開発者にとって、Firebugというツールが非常に便利らしい。
というわけで自分の勉強も兼ねて、Twitterのページ(2010年7月29日現在)が表示されるまでの時間をFirebugを使って測定してみた（測定環境は記事の最後に掲載）。
まずはtwitterのページを開く。そしてFirebugを起動して[接続]タブを有効にする。
この状態でF5ボタンなどを押してTwitterページを更新する。すると下記のように、Twitterのページがブラウザ上で表示し終えるまでのタイムラインが出力される。
上記のケースではブラウザ上で表示し終えるまでに約3秒かかっていた。何度か計測してみたが、おおよそ3秒前後になっていた。
タイムラインを詳細に見てみよう。全体のリクエストを通してもっとも遅いのは、twitter.comドメインにアクセスしてHTMLファイルを取得してくるという最初のリクエスト処理だった。なんと、リクエストを送ってから609msも待機させられている。この理由は【まとめ】で考察する。
また、赤枠で囲ったスクリプトファイルや画像ファイルの表示処理にも時間がかかっている。
ここでいう画像ファイルは、Twitterページ右上の広告画像に該当する。広告は貴重な収入源なので、多少パフォーマンスに影響が出ても我慢するしかないのが運営側の辛いところだろうか・・・。ちなみに、[304 Not Modified]と書かれている箇所は、ファイルが更新されていないのでキャッシュを利用していることを示す。
他には、Google Analytics関係のファイルにも時間がかかっているようだった。またここでもtwitter.comドメインとのやり取りに時間がかかっていることが分かる。
【まとめ】
Firebugを使うと、Twitterページのボトルネックは以下であることが分かった。
- twitter.com ドメインからのレスポンス
- 広告画像の表示
- Google Analyticsのスクリプト
ここで、「1.twitter.com ドメインからのレスポンス」がボトルネックになっている理由について少し深ぼりしてみる。コマンドプロンプトからtracertコマンドを用いて、twitter.comドメインへのネットワーク経路を調べてみた。
これを見ると、jpドメインからusドメイン、つまり日本からアメリカへ接続する際に地理的な問題で時間がかかっていることが分かる。ただ、それでも予想していたより随分早い。片道たかだか150ms程度である。なぜ609msもの待機時間が発生したのだろうか。何か他に要因があるのかもしれない。
そこでここからはちょっと推測。Twitterでは非常に多くのユーザが短時間で頻繁につぶやく。そのため、つぶやきを保存するデータベースの更新や検索処理がありえないほど大量に発生し、サーバの負荷が高くなる。サーバの負荷が高くなれば当然処理がおいつかなくなり、HTMLファイルの生成に時間がかかって今回のように長い待機時間が発生したのではなかろうか（他にも様々な要因が考えられるけど今回は省略）。
Twitterのような大規模なシステムでも安定したパフォーマンスを発揮するためには、最近ちまたで流行りの大規模分散技術の知識が必要になってくる。かなり難しいけど新しい技術でもあるので、先行して学んでおけば先輩たちを出しぬくチャンスにもなると期待している。
最後に、今回の測定環境は下記の通り。
回線・・・VDSL方式
通信速度(下り)・・・最大:100Mbps、実測:47.79Mbps
ブラウザ・・・Firefox 3.6.8
アドオン・・・Firebug 1.5.4
