PerfData

ストップウォッチのサイクル

Webパフォーマンス計測とプロファイリング

因果関係から表示速度を考える

2020年5月14日
著者: 竹洞 陽一郎

Webパフォーマンスは、システムパフォーマンス管理の一つです。
システムパフォーマンス管理は、コンピュータが生まれた時からある分野で、専門用語では、パフォーマンスエンジニアリングと言います。

「クルマができるまで」を例に

パフォーマンスエンジニアリングは、統計的品質管理が適用される分野です。
品質管理では、トヨタさんが著名な企業の一つですから、トヨタさんの品質管理を例にWebパフォーマンス管理を説明します。

トヨタさんのWebサイトに「クルマができるまで」というページがあります。
これが分かりやすいので、是非、ご覧下さい。

Webパフォーマンス計測は、このページで解説されている「3. 生産」の「(5)検査」に該当します。 しかし、もう1つ注目して頂きたいのが、「2. 生産準備」の「(3)設備トライ→品質確認→量産化」です。

パフォーマンスエンジニアリングでは、「プロファイリング」という段階があります。 これが、上述の「品質確認」に該当します。 つまり、自動車の試作品を作ってみて、それで生産性や品質をシミュレーションで確認するように、WebサイトやITシステムについても、本番環境に反映する前に、パフォーマンスに問題がないかを確認します。 これをプロファイリングと言います。 Chrome Developer Toolsは、正確な用語としては、システムプロファイラーであり、パフォーマンス計測ツールではありません。 https://en.wikipedia.org/wiki/System_profiler ですから、御社でも、これから自社でWebパフォーマンス管理をされるのであれば、プロファイリング(品質確認)のフェーズと、Webパフォーマンス計測(検査)のフェーズと2段階用意することをお勧めします。 この関係を開発フェーズに当てはめるとこのようになります。 #image(プロファイリングとWebパフォーマンス計測.png) ちょっと話が変わりますが、車を買うベストなタイミングはいつか、ご存じでしょうか？ ホンダの方に教えて頂いたのですが、モデルチェンジの直前だそうです。 何故かというと、品質検査をして生産を開始しても、細かな不具合が生産開始後、またお客様のクルマの定期検査で見つかるので、生産に反映されます。 だから、モデルチェンジの直前は、不具合が「枯れた」状態なのだそうです。 #image(品質フィードバック.png) Webパフォーマンス管理、Webサイトの管理も、これと同じ概念で、それがNetflixが提唱したDevOpsです。 プロファイリングでは主に計算量や計算時間を、Webパフォーマンス計測ではネットワーク要因や偶然誤差を確認します。 プロファイリングでの確認項目 • HTMLのパースの断片化 … HTMLが一気通貫でパースできているか？ • レンダリング・描画の回数 … レンダリングの計算が断片化し、数回に分かれてしまって、再描画を発生させていないか？ • 画像の読込が別スレッド化できているか … 画像の読込がmain threadに割り込んでしまっていないか？ • JavaScriptの読込 … JavaScriptの読込をdeferで別スレッドに持っていけているか？main threadで読込を生じさせていないか？ • JavaScriptの実行時間 … JavaScriptのパース・コンパイル・実行で時間が大きく消費されていないか？ • 非同期処理の管理 … 非同期処理は、Aの計算処理をして、その結果をサーバに送って、その結果を待ってる間にBの処理をしておくというものであり、最終的にはAの計算処理のサーバからのレスポンス待ちになります。サーバからレスポンスが遅延すると、結果としてAの計算処理は終わらず、遅延要因となります。そのような処理がないか？ • CSSの処理時間 … CSSの処理時間が長大になっていないか？10msを超えたら遅延。オブジェクト数の確認。 • 依存関係の確認 … 画像などが遅延している場合に、Call Treeを確認して、依存関係を調べる。依存関係がJavaScriptやCSSと絡んでいる場合は、その依存関係を解除できないか？ Webパフォーマンス計測での確認項目 いわゆる「品質管理」と呼ばれるのは、Webパフォーマンス計測の方です。 こちらで偶然誤差を調べます。 日本科学技術連盟や日本統計学会では、「バラツキが技術力」と言っています。 つまり、技術力が高いかどうかは、バラツキをいかに小さくして性能や品質を安定させられるか、という事です。 言い換えると、技術力は、色々な個別の技術要素があったとして、最終的には、性能や欠陥数などの数値の分布で確認が可能ということです。 基本的に、システム性能の個別の要素の分布は左右対称のベルカーブになりますが、それぞれの分布が異なるため、合体すると左右非対称分布となります。 そのため、通信業界ではパーセンタイルを使うのが一般的で、経産省・IPAの品質評価ガイドラインでもパーセンタイルを使った例になっています。 レスポンス時間 … HTMLの初出時間が100msを超えていないか？HTMLが遅い＝サーバの問題。 • DNS … DNSが遅延していないか？10msが理想。 • Connection …TCPの3 way handshakesに掛かった時間。数msが理想。 • SSL … SSL handshakesに掛かった時間。20～50msぐらいが理想。 • Wait … 待機時間。ボトルネックは、この待機時間を主に差します。HTTP GETやHTTP POSTのリクエストを送って、レスポンスが返ってくるまでの待ち時間で、この時間が長いと、サーバ側の処理に問題があるということを意味します。 • Load … レスポンスの最初の1byteから終わりの1byteまでを読み込む時間。見かけの読込時間と実際の読込時間が異なる場合があります。それは非同期処理が絡む場合です。例えば画像のAを読み込んでいるのに、そのAにJavaScriptの処理が絡み、そのJavaScriptは非同期処理である場合に、サーバからのレスポンスが返ってこないとJavaScriptの処理が終わらないので、結果として画像の読込も完了しないという事になります。 Render Start (表示開始時間) … 0.5秒を超えていないかどうか • JavaScript、CSS、画像の読込の遅延 … これらのファイルのいずれかが読込の遅延を引き起こしていないか？見た目の読込時間と実際の読込時間が異なる場合があるので、プロファイリングのCall Treeで確認する必要があります。 Document Complete (表示完了時間) … 1秒を超えていないかどうか • サードパーティの影響 … サードパーティのスクリプトなどで表示開始前や、表示完了前に読み込んでいるものがないか？ • サードパーティの処理 … 表示完了後に処理していたとしても、データの送信自身が失敗していると、費用を掛けている意味がない。データの送信に失敗している場合は、改善を要望する。 サーバの数値 • vmstatのr … 実行待ちプロセス数。できるだけ0にするのが理想。 • vmstatのcontext switch … コンテキストスイッチ数。3,000以下にするのが理想。 • vmstatのinterrupt … ハードウェア割込信号数。3,000以下にするのが理想。