Webサイトパフォーマンス管理の基礎知識

7,108 views
6,898 views

Published on

2016年3月5日に大阪・梅田で開催された、frontend conference 2016での講演資料です。

Published in: Internet
0 Comments
38 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,108
On SlideShare
0
From Embeds
0
Number of Embeds
1,644
Actions
Shares
0
Downloads
36
Comments
0
Likes
38
Embeds 0
No embeds

No notes for slide

Webサイトパフォーマンス管理の基礎知識

  1. 1. frontend conference 2016 Webサイトパフォーマンス管理 の基礎知識 2016年3月5日 竹洞 陽一郎 yoichiro.takehora@spelldata.co.jp ytakehora@catchpoint.com
  2. 2. 自己紹介  株式会社Spelldata 代表取締役社長、Catchpoint Systems日本代表  ACM(Association for Computing Machinery)会員  CMG(Computer Measurement Group)会員  ISACA(Information Systems Audit and Control Association)会員  日本統計学会賛助会員  html5j パフォーマンス部部長  統計学を基礎から学ぶ! 中西塾主催  Webサイトパフォーマンスに関係する仕事を始めて、もう13年目  やってきた事  VMware … 日本人初のVCPトレーナー  Akamai … プロフェッショナルサービス  Verizon Business … プリンシパルコンサルタント  Keynote Systems … 日本代表
  3. 3. NetScaler – 2002年当時
  4. 4. Catchpoint SystemsのCEO Mehdi Daoudi
  5. 5. 統計学を基礎から学ぶ! 中西塾 第一期 2014~2015
  6. 6. 「第7章 コンテンツの解析」 配信品質と情報品質
  7. 7. 今日、お話する内容  「速さ」はなぜ、重要なのか?  人によって違う速度の感じ方  遅延は止める理由  Webサイトパフォーマンス計測手法  その秒数は、何をどこまで保証できるのか?  層別に計測・分析する  Webサイトパフォーマンス改善の手順  おまけ  まとめ
  8. 8. 「速さ」はなぜ、重要なのか? ユーザが、今最も臨むこと
  9. 9. 「パフォーマンスは、重要だと思うんですが、 今、他の優先事項があるんで…」
  10. 10. 「遅いサイトは二度と行かない」 参照資料:Compuware(2012年)
  11. 11. Webサイトを見続けてもらうチャンスは一度きり お見合いパーティー並みにシビア
  12. 12. 見てもらえなければ、「他の優先事項」を 頑張っても水の泡です。
  13. 13. Webサイトに期待するもの Webサイトに期待すること 1 2 3 4 サンプ ル数 平均レート コンテンツの新しさや更新頻度 39% 400 29% 295 19% 191 13% 127 1,013 2.04 パフォーマンス (バッファリングなしで、動画再生、 ページの読み込みが速い等) 52% 523 26% 266 9% 87 14% 137 1,013 1.84 モバイルサイトとデスクトップサイト の体験が同一であること 20% 205 27% 274 35% 356 17% 177 1,012 2.50 パーソナライズされたコンテンツ 12% 117 18% 182 26% 259 44% 447 1,005 3.03 Limelight Networks http://img03.en25.com/Web/LLNW/%7Bb97f8e45-2370-4f4b-8c8e-fa4141051c72%7D_2014StateoftheUserExperience.pdf
  14. 14. パフォーマンスは、最優先事項です!
  15. 15. 速いサイトは、見てもらえる
  16. 16. Webサイトの高速化を行うと、 皆さんの努力が、より大きな結果になります!
  17. 17. 人によって違う速度の感じ方 精神物理学の最新研究に学ぶ
  18. 18. 時間経過の感じ方は、性別や年齢で違う  男性より、女性の方が気が短い  若者より、年配の方が気が短い
  19. 19. ヴェーバー ― フェヒナーの法則  精神物理学  ヴェーバー ― フェヒナーの法則  心理的な感覚量(心理量:R)は、物理的な刺激の量(物理量:S)の対数に比例 する  𝑅 = 𝑘log10 𝑆 (kは感覚定数)
  20. 20. ヴェーバー ― フェヒナーの法則を グラフで表現すると 心理量R 物理量S
  21. 21. 「ジャネーの法則」 時間感覚 = 現在進行中の時間(一定) 生きてきた時間(年齢) = ⊿𝑇 𝑇 5歳の子の1日は、50歳の人の10日に相当する
  22. 22. 年齢による時間の感覚のズレ Yomiuri Online ― 「こころの元気塾」 時間感覚…年齢、状況でずれる「心の時計」 http://www.yomidr.yomiuri.co.jp/page.jsp?id=35447
  23. 23. New Scientistの記事  ミネソタ大学のGeoffrey Ghose とBlaine Schneiderの研究発表 (2012年10月30日)  ニューロンの活動が活発である と、時間感覚が伸びる  逆にストレスを感じているときは、 アドレナリンがニューロンの活 動を妨げるため、時間感覚が 速くなる http://www.newscientist.com/article/dn22446-brain-circuits-run-their-own-clocks.html
  24. 24. 対象顧客の年齢層によって、 目標の表示速度を定める
  25. 25. 年齢層に対するバイアスを外す  どんな年代であっても、新しいものが好きな人と、そうでない人がい る  若い世代=トレンドについてきている、年配の年代=トレンドについ てこれない、などとは思わないように!  総務省「平成26年情報通信メディアの利用時間と情報に関する調 査」などを参照して下さい。  http://www.soumu.go.jp/main_content/000357568.pdf
  26. 26. Webサイトパフォーマンス改善手法 Best Practice V.S. Evidence-based Improvements
  27. 27. ベストプラクティスで速くなるのか?
  28. 28. 速くなりません
  29. 29. 「ベストプラクティスを適用してるので、 うちのサイト、速いですよ」  ドヤ顔で挑まれることが多々あ る  計測すると、遅い
  30. 30. あの「ベストプラクティス」とは何か? 問題の事象 解決策 解決
  31. 31. ベストプラクティス 「ベストプラクティス」? 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決
  32. 32. 事象の背後にある原因が違うと、解決策は 変わる 問題の 事象 解決策B 解決原因B 原因A 原因C 解決策C 解決策A
  33. 33. 事象例:画像が重い  計測してみたら、画像が重いと出た  ベストプラクティス: 画像を軽量化しなさい→速くならない  過去の事例  Windowsのサーバを使っており、NTFSでフォーマットされたディスクパーティ ションを80%以上使っていた  NFSでNASをマウントして使っていた  HTMLの生成と、画像の配信を同じディスク上で行って、ディスクのアクセス 競合が発生していた
  34. 34. ベストプラクティスとは?  ある結果を得るのに、最も効率の良い技法、手法、プロセス、活動 の事。  ベストプラクティスは、変化のない固定的なものではない。  ベストプラクティスとは、常に学習し、改善し続ける精神であるとも言 える。
  35. 35. 健康法
  36. 36. 日本人のシニア世代の健康法 参考資料:MDBネットサーベイ(2007年12月21日)
  37. 37. 健康法を実践すれば、病気は治るのか?
  38. 38. 病気は、ちゃんと診察しないといけません
  39. 39. 統計的思考の問題解決法 PPDACサイクル Problem (問題の明確化) Plan (実験・調査の計 画) Data (データの収集) Analysis (データの分析) Conclusion (問題の解決)
  40. 40. 日本政府の統計学教育強化への取り組み
  41. 41. 診察=計測の重要性 しかも、その診察は、実行可能なデータを もたらさなければ意味がない
  42. 42. 治療=改善作業
  43. 43. エンジニアは「医師」であるべき
  44. 44. Webサイトパフォーマンス 計測手法 目的に応じた正しい計測手法を選択する
  45. 45. 計測の仕方 Last Mile First MileMiddle Mile web server エンドユーザ NTT KDDI エンドユーザ 1次ISP RUM (Real User Monitoring) Synthetic Monitoring Server-side Monitoring
  46. 46. 各計測の補完関係 計測種別 長所 短所 サーバサイド計測 (Server-side Monitoring) インターネットの影響を受けていない Webサーバ本来の表示速度を計測で きる。 サードパーティーコンテンツ、インター ネットの通信状況の影響が見られない。 合成計測(Synthetic Monitoring) インターネットの影響を受けた、ISP毎 の表示速度を計測できる。 実験計画法に基づいた計測により、問 題点を特定する事が可能。 計測対象ページ以外については、 データが得られない。 リアルユーザ計測 (Real User Monitoring) エンドユーザが体験している表示速度 を取得することが可能。 エラー率が分からないので可用性分 析には使えない。 エラーになったユーザのデータは取得 出来ない。 実験に介入できていないので、因果関 係の証明はできない。 表示速度に関わる変数が非常に多く、 それらの数値が得られないため、品質 管理では使えない。
  47. 47. 品質管理の原則  コントロールできるところに集中する。 コントロールできないところのデータを取っても無駄になる。 web server エンドユーザ NTT KDDI エンドユーザ 1次ISP コントロール可能な範疇 コントロール大コントロール小 コントロール不可能な範疇
  48. 48. お勧めの計測手法 ― 合成計測  統計的品質管理で重要な「実験計画法」に基づいた計測  Actionable Data(実行可能データ)が取得できる  数学的に証明が可能
  49. 49. 実験計画法に基づく計測  実験計画法  統計学の大家R・A・フィッシャー が1920年代に発案  現在の統計分析のデータ取得の 基礎となる。
  50. 50. 実験計画法  三つの基本原則  局所管理化 影響を調べる要因以外の全ての要因を可能な限り、一定にする。  反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条件で反復して行 う。  無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響を取り除き、 偏りを小さくするために条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、ランダム化する。
  51. 51. The Art of Computer Systems Performance Analysis Techniques for Experimental Design, Measurement, Simulation, and Modeling 米国ワシントン大学をはじめとして、コンピューターシステムのパフォーマンス計測 についての定番教科書
  52. 52. 合成計測における実験計画法3原則の適用  三つの基本原則  局所管理化 影響を調べる要因以外の全ての要因を可能な限り、一定にする。 → 計測機器の統一、回線帯域の統一、ブラウザの統一  反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条件で反復して行 う。 → 5~60分に1回の計測を24時間365日自動で計測する  無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響を取り除き、 偏りを小さくするために条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、ランダム化する。 → 計測を行う時間をランダム化
  53. 53. 計測時間のパターン化
  54. 54. 計測時間のパターン化
  55. 55. 計測時間のランダム化
  56. 56. 計測時間のランダム化
  57. 57. 24時間365日計測する必要性  インターネットは高速道路と非 常によく似ている  自分が出発する道路状況だけ を見ていては、目的地に辿り着 く時間の予測が狂うのと同じ。  途中経路の混雑状況をチェック しなくては、確かな到着予想時 刻は算出できない。  インターネットの中は、常に状 況が変わっています。  ユーザに自社Webサイトが確実 に閲覧可能な状態かどうかは、 計測しないと分からない。
  58. 58. その秒数は、 何をどこまで保証できるのか? 「標本」と「真の値」
  59. 59. Navigation Timing v2
  60. 60. Resource Timing
  61. 61. 0.645秒 ― これはどれだけ「確かな」数値 か?
  62. 62. 1時間のデータ
  63. 63. 6時間のデータ
  64. 64. 24時間のデータ
  65. 65. 1週間のデータ
  66. 66. 2週間のデータ
  67. 67. パフォーマンスの数値は一意に定まらない
  68. 68. ラプラスの魔 もしもある瞬間における全ての物質の 力学的状態と力を知ることができ、か つもしもそれらのデータを解析できるだ けの能力の知性が存在するとすれば、 この知性にとっては、不確実なことは 何もなくなり、その目には未来も(過去 同様に)全て見えているであろう。 — 『確率の解析的理論』1812年
  69. 69. 真の値には、 確率的に近づいていくしかない
  70. 70. 母集団と標本(サンプル) 神のみぞ知る母集団の真の平均の値 μ 標本(サンプル) 母集団 標本から得られた平均 തx
  71. 71. 1回だけの計測は、何も保証できない  統計学的には、最低でも1日あたり20~30の標本が欲しい  標本数が少ない場合は、検定が必須  データの粒度  日単位の表示速度を算出したいのか  時間単位の表示速度を算出したいのか
  72. 72. 偏差 ~ 平均値との「距離」を見る 平均 パフォーマンス 時 間 の 経 過 平均と実際の計測値との差 1秒 2秒 3秒 4秒 5秒 6秒 7秒 8秒
  73. 73. 平均値と標準偏差
  74. 74. 大数の法則  nが大きい時、標本平均തxは、真の平均μに近づく
  75. 75. 中心極限定理  nが大きい時、標本平均と真の平均の差、 തx -μが従う分布は、平均0、 分散σ2/𝑛の正規分布に近づく 平均തx 平均തx 平均തx
  76. 76. 中央値(Median)と75パーセンタイル値の 変化 中央値 75パーセンタイル値 1時間 896.00ミリ秒 1087.00ミリ秒 6時間 886.50ミリ秒 1057.00ミリ秒 24時間 855.00ミリ秒 950.00ミリ秒 1週間 847.00ミリ秒 943.00ミリ秒 2週間 846.00ミリ秒 962.00ミリ秒
  77. 77. Webサイトのパフォーマンス管理とは、標準 偏差を小さくしていくこと=品質管理
  78. 78. 層別に計測・分析する インターネットは高速道路と同じ
  79. 79. 東京(NTT)
  80. 80. 東京(KDDI)
  81. 81. 東京(AWS)
  82. 82. 大阪(Azure)
  83. 83. 層別に分析する重要性  性格が異なる集団=異なる母集団  いっしょくたにして計算してはいけない
  84. 84. 数値による要約 平均値 標準偏差 四分位 範囲 0% 25% 50% 75% 100% 大阪 Azure 1120.98 463.01 287.00 698 907 1008 1194 7965 東京 AWS 839.68 385.50 145.25 533 712 771 857.25 6184 東京 KDDI 921.90 548.69 131.00 551 802 865 933.00 18545 東京 NTT 844.77 372.71 115.00 539 738 789 853.00 7725 N=2121
  85. 85. 以下のグラフの平均値は同じ 1秒 2秒 3秒 4秒 5秒 6秒 7秒
  86. 86. ヒストグラム分析 - 配信品質を見る
  87. 87. 箱ひげ図 ― 配信品質を比べる
  88. 88. Webサイトパフォーマンス 改善の手順 PPDACサイクルを用いる
  89. 89. Webサイトパフォーマンス改善の手順 1. 計測計画を立案する 2. データの収集 3. データの分析 4. 問題を解決する 5. 計測して、事前・事後の変化を見る 6. 次の問題を明確化
  90. 90. 1. 計測計画の立案  主要動線でのページ遷移計測  ユーザ体験としての始めから終わりまでの時間としてのパフォーマンスを計 測する  分散の加法性  トップページ→商品検索→商品詳細→カート→決済という、5ページの遷移がある場合、 この動線の平均とばらつきは、各ページの平均やばらつきを合計したものとなる  制約条件の理論(TOC: Theory of Constraints)  A chain is only as strong as its weakest link.  主要動線が分からない場合  トップページ〜システムの特性が分かりやすい  RUMで計測して、全体を把握してみる
  91. 91. 「ザ・ゴール」
  92. 92. 2. データの収集  エラー率をまず把握する  繋がらないのが、最も悪い現象  10秒以上かかっている場合は、エラーと同じと見なす  ユーザーは離脱してしまう  各種測定タグを入れていても、データを取得できないことが多い  全てのページを計測する必要はない  「テンプレート」と「サーバ構成」で考える  測定の単位を決める  1日単位の場合、最低でも1時間に1回の計測→24の標本を得ることができる  時間単位の場合、最低でも5分に1回の計測→12の標本を得ることができる  最低でも3日は計測する  普通は、2週間以上計測する  日次パターン、週次パターンを把握するため  月次パターンを把握するためには、3ヶ月以上計測する
  93. 93. 3. データの分析  全体から部分へと降りていく  たまたまなのか、よくあることなのかを判断  パターンを把握する〜外れ値と思っても、実はパターンであることが多い  下のレイヤーから上のレイヤーへと分析を進める  ネットワーク→ハードウェア→OS→アプリケーション→HTML, CSS, JavaScript  ここ7〜8年の傾向として、サードパーティーコンテンツが遅延要因に なっているので、サードパーティーと交渉するための証拠としての データが必要
  94. 94. スマートフォンサイト(LTE)
  95. 95. 週次パターンの例
  96. 96. 接続待機状態の画像 ― Waterfall図
  97. 97. Google Analyticsの遅延 Chrome開発者ツールで 取得できる範囲
  98. 98. Chrome開発者ツールやFirebugで 取得できるデータの限界を知っておく
  99. 99. Google Page Speed Insightでは分からない
  100. 100. 4. 問題の解決  動線のページ遷移中のWeakest Link(一番遅いページ)から解決す る  パレートの法則で改善する  「何かを加える」のではなく、「何かを減らす」考え方が大事  KISS(Keep It Simple, Stupid!)の法則  デザインの語源は「削る」という意味である。不要なものを消して、最適なも のを選ぶことだ。けっして「足して飾る」ことではない。(森 博嗣)  連動性を考える  画像を減らす→HDDのアクセスが軽減される  Cache-Control Headerを設定する→If-Modified-Sinceリクエストが減る→ネッ トワークが楽になる(Self DoS攻撃)  本質的な情報だけを残す→ビジネスモデルや、セールスモデルの見直し  影響の範囲を考える  DNSのTTLを短くする→DNSサーバの負荷が上がる、携帯網のDNSの負荷が 上がる
  101. 101. パレートの法則(80:20の法則)で改善  「全体の数値の大部分は、全体 を構成するうちの一部の要素 が生み出している」  全体の時間の80%を占める20% の遅延要因を探す
  102. 102. SSL NegotiationDNS Lookup Content Download Initial Connection First Byte Download Client Time 自社DNSサーバ 負荷 相手先DNS サーバ負 荷 DNS TTL DNS TTL DNS攻撃負 荷 接続負荷 Keep Alive設定 同時接続数 ページ滞留時 間 ページあたりの オブジェクト数 ページあたりの 容量 DNSラウンドロビン 暗号化方 式 瞬間鍵処 理能力 暗号化対 象 プログラミング言語 型類 推 CP U メモリ Webサーバ処 理時間 ハードウェア性 能 IOPS 動的生 成処理 サーバサイ ドキャッシュ DBサーバ処 理時間 DBタイプ ACID特性データ量 データ モデリング Webサー バ MO D プロセ ス優先 度 ディスク接続方式(Fibre Channel, iSCSI, SATA) ファイルシステ ム CP U ディスクアクセ ス 競合制御方式 ストレージ種別(SSD, HDD, Hybrid) パーティショ ン サイズ 暗号強 度 ロバストネス 性 ディス ク 使用 量 キャッシュメモリ動作方式(Write Through, Write Back) Webブラウザの種 類 ブラウザキャッシュ設 定 キャッ シュ有効 期限 アクセス パターン 圧縮配 信 事前圧 縮 CP U Web サ イ ト パ フ ォ ー マ ン ス DOM処理特 性 HTTP同時接続 数 独自実装 接続の順番 自社接続ドメイン 数 3rd Party接続ドメイン 数 ネットワーク状 態 レイテンシ 経路 JavaScript 処理性能 HTMLドキュメント構 成 HTML記 述 文法エ ラー divネスト構 造 DOMオブジェクト 数 ネットワーク状 態 帯域 経路 レイテンシ CSS定義構 造 読み込みファイル 数 Override定義 数 文法エ ラー SSL通信検査 JavaScriptコー ド 処理効率 バグ含有 率 接続応答 性 複雑 度 接続方式 実装方 式 特性要因図
  103. 103. ネットワークは混雑する一方
  104. 104. 「意外と」不安定なインターネット網  インターネットは、どこかの組織が 一元的に統括・管理しているわけで はない。  様々なネットワーク(AS)の集合体  ネットワーク間で、パケットをバケツ リレーしている  想像を絶する構成ノード数  ノード数の増加は、「ムーアの法則」(18ヶ 月毎に倍になる)に従っている  常にどこかでノードが故障している 2016年3月7日 104 ©2012 Keynote Systems, Inc. http://iopscience.iop.org/1367-2630/10/12/123027/fulltext/ AS(autonomous system)レベルでの ノード数の増加
  105. 105. 郊外の基地局配置 1つの円で20~30Kmをカバー。 その分、電波が強い。 色の違い=チャネルのグループの違 い。 NTTドコモの場合、 800MHz帯を使い、 15MHzの幅がある。 それを12.5KHz幅で区切ることで、 15MHz/12.5KHz = 1200チャネルを持 つ。 もし7つのグルーピングを作るとすると、 各基地局は 1200/7≒170チャネルと なる。
  106. 106. 都市部の基地局配置 1つの円で200~300mをカバー。そ の分、電波が弱い。
  107. 107. ソフトバンクの「マイクロセル化」
  108. 108. 制約の多いモバイルネットワーク  電波干渉という問題  ユーザがそこに多く居るからと言って、電波塔(基地局)は増やせない  基地局を乱立するとどうなるか? – “Dirty WiFi”と同じ状況に  電波の「谷間」~基地局と基地局の中間点  「繋がる」事と「通信できる」事は、違う  アンテナの表示が5本中5本立った! → 電波強度が十分というだけ  携帯基地局は、混雑するとネットワークを守るためにパケットを意図的にド ロップする  レイテンシの問題  モバイルネットワークのレイテンシは3Gで100~200ms、4Gで40〜60ms 2016年3月7日 108 ©2012 Keynote Systems, Inc..
  109. 109. 携帯網のパケットドロップ率の影響  無線基地局のパケットドロップ率が20%、1パケット1KBの場合 1.全部で100KBのデータを送信する場合  失敗回数の期待値={100×(1-0.8)}÷0.8=25  失敗回数の分散={100×(1-0.8)}÷0.8^2 =31.25  失敗回数の標準偏差は、31.25の平方根、約6となります。  2σの考え方だと、 下値=失敗回数の期待値-2×失敗回数の分散の平方根 上値=失敗回数の期待値+2×失敗回数の分散の平方根  2σ(シグマ)の範囲を計算すると、(25-2×6, 25+2×6)=(13, 37) 95%の確率で13~37回の失敗(パケットドロップ)が発生します。 2.全部で1,000KBのデータを送信する場合  失敗回数の期待値={1,000×(1-0.8)}÷0.8=250  失敗回数の分散={1,000×(1-0.8)}÷0.8^2 =312.5  失敗回数の標準偏差は、312.5の平方根、約18となります。  2σ(シグマ)の範囲を計算すると、(250-2×18, 250+2×18)=(214, 286) 95%の確率で214~286回の失敗(パケットドロップ)が発生します。
  110. 110. 統計的品質管理手法を使って、 確実に高速化させる
  111. 111. 5. 次の問題の明確化  高速化すると、必ずアクセス数が増える  今まで、問題として見えなかった箇所が、問題となる
  112. 112. ルウディーのルタバガ法則  「第一番の問題を取り除くと、第 二番が昇進する。」  著名なシステムコンサルタント、 G・M・ワインバーグ
  113. 113. Webサイトのパフォーマンス管理は永遠に 続く → DevOpsの品質評価基準
  114. 114. DevOpsとは  開発担当者と運用担当者が連 携して協力する開発手法  Velocity 2009でFlickrのエンジニ アによって、初めて、この言葉 が使われた
  115. 115. 具体的なイメージを掴みたいなら…  「The DevOps 逆転だ!」  日経BP社 2200円  原題”The Phoenix Project”
  116. 116. おまけ 日本のEコマースサイトTop300のデータ
  117. 117. トップページの容量
  118. 118. トップページの接続ホスト数
  119. 119. この接続ホスト数でHTTP/2を導入したら、 絶対遅延します。
  120. 120. トップページのオブジェクト数
  121. 121. HTML文法エラー数
  122. 122. HTML文法エラー数0〜200個
  123. 123. まとめ Webサイトパフォーマンス管理の基礎知識
  124. 124. まとめ  Webサイトパフォーマンス管理は、品質管理です  統計学を学び、品質管理手法を学ぶと、Webサイトパフォーマンス の管理をする上で、幸せになれます  Webサイトの高速化が何よりも大事です  パフォーマンスの遅延は「病気」ですから、健康法の実践ではなく、 きちんと診察をして治療をしましょう  いろいろ計測手法がありますが、実験計画法の三原則が鍵を握り ます  標本と真の値の違いを認識しましょう  Webサイトパフォーマンスの改善にはPPDACサイクルを適用しましょ う  DevOpsでは、パフォーマンスと可用性が品質の重要な指標です
  125. 125. 正しい、失敗しない Webサイトパフォーマンス管理のやり方 =統計的品質管理で、 日本のWebを良くしていきましょう!
  126. 126. Q&A

×