1~5までは従来の開発手法

最近のクラウドコンピューティングでは6以降のステップをサービスとして提供していることが多い

パフォーマンスの解釈は主観的に判断されることが多い。

例えばディスクI/Oの平均応答時間は1msの場合、これは「良い」でしょうか？それとも「悪い」でしょうか？

　応答時間（レイテンシー）は最も優れた測定基準の1つですが、レイテンシーの情報を解釈することは困難です。あるメトリクスが「良い」か「悪い」かは、ある程度、アプリケーション開発者とエンドユーザーの期待する性能に依存する場合があります。

主観的なパフォーマンスは、目標とする平均応答時間を設定したり、リクエストの何パーセントが特定のレイテンシ範囲内に収まるように要求するなど、明確な目標を定義することによって客観化することができます。この主観に対処する他の方法として、レイテンシ解析などが第2章「方法論」で紹介されています。

複雑性に置いても、昨今のシステムは異なるコンポーネント同士が相互作用しており原因解明のあたりを正確につけるのが難しい。また局所的な改善になることも多く全体のパフォーマンスを大きく向上させることは難しい。

レイテンシーとは、待ち時間のことで、重要な性能指標の一つである。広義には、アプリケーションのリクエスト、データベースのクエリー、ファイルシステムのオペレーションなど、あらゆるオペレーションが完了するまでの時間を意味します。例えば、Webサイトが完全にロードされるまでの時間（リンクがクリックされてから画面が表示されるまでの時間）を表すことができます。これは、お客様とウェブサイトプロバイダー双方にとって重要な指標です。待ち時間が長いとフラストレーションが溜まり、ユーザーは他の場所に行ってしまう可能性があります。

レイテンシーを指標とすることで、最大限の高速化を見積もることができます。例えば、図1.3は、データベースクエリに100ms（レイテンシ）かかり、その間に80msのディスクリードのブロック待ち時間がある場合を示しています。ディスク読み出しがない場合（キャッシングなど）の最大性能向上は、100 ms から 20 ms まで（100 - 80）5倍速くなる。これは推定される高速化であり、この計算により、ディスク読み出しが原因でクエリが最大5倍遅くなるという性能上の問題も定量化できる。

他の指標を使用する場合、このような計算は不可能である。たとえば、IOPS（I/O operations per second）は、I/Oの種類に依存し、直接比較できないことが多い。ある変更によってIOPS率が80%低下した場合、パフォーマンスにどのような影響が出るかを知ることは困難です。IOPSは5倍減るかもしれませんが、これらのI/Oのサイズ（バイト）がそれぞれ10倍になったらどうなるか？

観測性とは、観測によってシステムを理解することであり、それを実現するためのツールを分類したものである。カウンタ、プロファイリング、トレースなどを利用するツールが含まれる。

例えば、vmstatなどLinuxに標準で搭載されている計測コマンドを使用して、モニタリング基盤を構築することが推奨される

モニタリング項目の解釈方法は、第２章方法論の8節統計情報で詳細を述べる。

システムパフォーマンスにおいて、プロファイリングとは通常、サンプリングを行うツールの使用を指します。これは、測定値のサブセット（サンプル）を採取し、対象物の大まかなイメージを描くことです。CPUは一般的なプロファイリング対象です。CPUのプロファイリングによく使われる方法は、CPU上のコードパスの時間間隔サンプルを採取することです。

トレースはイベントベースの記録であり、イベントデータをキャプチャして保存し、後で分析したり、その場で消費してカスタムサマリーやその他のアクションに利用することができます。

システムコール(Linux strace(1))やネットワークパケット(Linux tcpdump(8))などの特殊用途のトレースツールや、あらゆるソフトウェアやハードウェアイベントの実行を分析できる汎用トレースツール（Linux Ftrace、BCC、bpftraceなど）がある。これらの全方位型トレーサは、様々なイベントソース、特に静的および動的インスツルメンテーション、そしてプログラマビリティのためのBPFを使用する。

以下は著者が、パフォーマンスの問題に対して最初に使用するツールベースのチェックリスト