パフォーマンス解析の観点

ボトルネック、もしくはレイテンシが支配的な処理以外を高速化しても意味がない。高速化する価値のあるポイントを見極めるには、システムのパフォーマンス状況を把握する必要がある。書籍 Systems Performance にはシステムパフォーマンスの解析の方向性として、ワークロード解析とリソース解析の2軸があると書かれている。

screen shot 0027-08-30 at 2 16 56

ワークロード解析はアプリケーション的な視点での解析で、リソース解析はOS/ミドルウェア的な視点での解析である。 OSのソフトウェアスタックに対して、前者はトップダウン、後者はボトムアップな解析であると言える。アプリケーション的な最適化の余地がだいたい8割でOS/ミドルウェア的な最適化の余地は2割と、Systems Performanceの著者がどこかで書いてた気がする。

リソース解析は結構得意で好きなんだけど、異常なパフォーマンス劣化を抑えることはできても、劇的にパフォーマンスがよくなったりはしない。だいたいリソース解析から発見したボトルネックを潰すと劇的に改善できるイメージがある。

ワークロード解析

アクセスログ解析
Devel::NYTProf 的なプロファイラによる解析
pt-query-digest などによるMySQLのスローログ解析

リソース解析

システムというのは細かくコンポーネントに分けると待ち行列が連続的に組み合わさったものだと思う (参考: リトルの法則 )。例えば、リクエストを受け取ってレスポンスを返すまでを考えると、パケットを蓄積するキュー => TCPコネクションを受け付けるキュー（syn backlogと listen backlog) => Starletのワーカーキュー(キューじゃないけど) => MySQLのコネクションを受け付けるスレッド => MySQLのI/Oスレッド => ファイルシステム/ブロッグデバイスレイヤのI/Oキューのようにいくつもの待ち行列がある。あとは全体でみてこれらの処理をスケジュールするCPUコアごとのランキューなど。

この中からtopとかdstatを使ってどの待ち行列がボトルネックを見つけるなのか見つける必要がある。リソース解析の観点でみて、Webアプリケーションにとって理想的な状態はWebサーバのアプリケーションロジック部分のCPU時間がボトルネックである状態、ということになる。

ISUCONの場合では、やはりワークロード解析が支配的なイメージ。