CPU、ストレージ、NWの処理時間を”体系的”に理解する

システムの処理時間はCPU、ストレージ、ネットワークの処理時間の合計である。それぞれの処理時間の規模感が理解できるとパフォーマンスチューニングでどこがボトルネックか判断できるようになる。

例えば、DBからのレスポンスタイムが3秒だったとき、「CPUで数マイクロ秒、IOで数秒、NWで数ミリ秒でほとんどがIOの処理時間だろう」というように規模感がわかればどこにフォーカスするべきか判断できる。また、実測値を見た時、その値が正常な規模感か判断できる。パフォーマンスを考えるときは、このように規模感を見た方が良い。詳細な値にフォーカスしてもキャッシュ等の影響で値はかなりぶれるので意味がない。複雑化してしまって判断を誤まるリスクを高めてしまうデメリットの方が大きい。

以下になるべく体系化した形で処理時間を整理する。
下記の2-7行目は桁位置と処理単位の関係をビジュアル化したものである。8-15行目はハードウェア（およびDB）ごとに1レコード処理する場合の処理時間をビジュアル化している。HWごとの処理時間の規模感をイメージできるようにした。

• NW-japan-us
  • 日本とUS間のネットワークレイテンシで100msec規模となる。クラウドでリージョンを跨いで通信をすると、このぐらいの処理時間となる。なるべく多くのデータを同時（10000件等）に転送することでレイテンシを軽減できる。光ファイバーで光速に近い速度で転送しても距離が離れているとこれぐらいの時間を要することになる。
• NW-local
  • ローカルネットワークだと1msec規模で以下のハードディスクのランダムIOと同程度となる。
• Hdd-randam-io
  • ハードディスクのランダムIO。5msec程度で1秒間に200回程度IOが可能なのはよく知られている。
• SSD-randam-io
  • SSDの場合はディスクヘッドの機械的な移動を伴わないためハードディスクよりも5倍〜10倍程度高速。尚、HDDのシーケンシャルIOも同じぐらいの速度。
• SSD-sequnsal-io
  • SSDのシーケンシャルIO。一回のIOで同時に多くのデータを取得できるためランダムIOより高速。
• DB-fetch
  • DBがバッファから1行データを取り出すのに要するCPUの処理時間。
• DB-sort
  • DB-sort は N*logN * DB-operator と考える。N*logNは約10程度、DB-operatorはdb-fetch/10 なので db-fetchと同程度となる。
• CPU-loop(c言語)
  • C言語のループ一回の処理時間。競技プログラミングでループが1千万回/秒程度なのはよく知られている。
• DB-operator
  • データベースでwhere句が1行処理するときのCPUの処理時間