何をもって速いとするか

これを書くきっかけの一つでもあるので、まずは前提の話をする。

この前提がはっきりしないとパフォーマンスの話はできない。
しかし、今の Web ではこれこそが一番難しいんだと思う。

推測するな測定せよ -> 何を？？

ロブ先生の引用については説明しないが、パフォーマンスには測定が不可欠だ。

Web のパフォーマンスという意味で、真っ先に測られるものの一つに Response Time があったと思う。

Web での Response Time とは、リクエストがサーバに届き、サーバがそれを処理してレスポンスをクライアントに返すのにかかる時間。
つまりサーバが消費する時間という形で測られて、だからサーバのログに残せる。

なぜ Response Time を測ったか

サーバがレスポンスを作るのにかかる時間と、そのレスポンスをブラウザに送り出した後で比べれば、
前者の方が支配的な時間を使っていたからというのが有ると思う。
チューニングは必ずボトルネックから始まる。

多くの場合は、サーバ内で発生する File や DB や 別サービスへの I/O にかかる時間が支配的だった。

相対的に、ブラウザがそれを表示するのにかかる時間は無視されていた。
それを届けるための間にあるネットワークのチューニングも、そこまで問題視されなかった。

また、 Response Time は 測りやすい という性質もある。サーバの設定を少しいじれば、 Access Log に入れるのもそんな大変じゃなかった。

でも、それはもう昔話だと思う。

Response Time で足りるのか

Response Time がチューニングで速くなれば、多くの場合「速くなった」と体感できるだろう。
そして、このチューニングはある意味かなり成熟してきていると思う。

成熟というのは、簡単という意味ではないし、だれでもできるという意味でもない。
過去の ISUCON なども、まさしくここを大きな指標として戦っていた。
つまり、競技にできるくらいスキルが必要だ、軽視してはもちろんいけない。

Response Time は簡単に台無しにできる

ただし、例えばそれがたくさんの画像を表示するポータルサイトだったり、
最初の表示から刻々と変化するもの、 SPA 的なものだった場合、
フロントの作りによっては、 Response Time の成果をいとも簡単に台無しにできる場合がある。
どんなにバックエンド側をチューニングしても、表示部分も適切に作られていないと、その成果は活かせない。

Response Time の改善にも限界がある

Response Time でできることは、リクエストがサーバに入ってレスポンスが出てくるまでだすると、
逆を言えば、それ以外は全てこの数値に反映されない。

つまり、この数値だけを拠り所にしていると、この数値が最適化の限界が、全体の限界を意味する。
しかし、すでにここ以外にも、チューニングが可能な場所がたくさんあることがわかっている。

Response Time = 全体の半分

対象を「クライアントとサーバのインタラクション」だとすると、
サーバが消費する時間以外にも、クライアントが消費する時間や、両者間での転送時間もある。

そしてそれは年々無視できない重要性を帯びている。

平たく言えば、 Response Time で測れているのは、全体の半分程度にすぎない。

あと何を測ればいいのか？

実はこれが、長いこと抜けていたミッシングピースであり、最近やっと出てき始めてきたという体感。

具体的には以下を考える必要がある。

• 測るべき指標
• それを数値化する手段
• それを取得するツール
• それを最適化するノウハウ

そして、例えば High Performance Web Site あたりから徐々に出てきているが、
時間とともにそのピースも形を変えている。

個人的にはこの辺は出てきたばかりで、先ほど言った意味での「成熟」とはほど遠いと思う。
でも、実際はあるものを使ってやっていくしか無い。その結果成熟させていくしかない。

次はまず、その指標と数値化あたりを書きたい。