法則一覧
コラム
速くしたいとき
何かが遅いとき、まず手をつけたくなるのは自分の知っている部分だ。このコラムは、時間が実際にどこで使われているかを見つけるところから、速くできる限界、待ち時間が伸びる理由、そして速さを保ち続ける手までを順に読む。
多くの場合、誰かが前から怪しいと思っている部分から始まる。
早すぎる最適化
計測する前に最適化すると、ボトルネックでない箇所に工数を使ってしまう。心得：測ってから直す。後で直せない設計だけは先に考える測ると遅い工程がいくつも見つかる。仕事がそれらを順に通るなら、どれだけ流れるかを決めるのはそのうち一つだ。
制約理論
システムの処理量は、最も詰まっている一か所で決まる。心得：改善はボトルネックに集める。ほかはそれを待っているだけだボトルネックを見つけても、直してどれだけ効くかは、それが全体のどれだけを占めるかで決まる。
アムダールの法則
ボトルネックが別の場所にあれば、一部を速くしても全体はほとんど速くならない。心得：何かを速くする前に、ボトルネックを見つけるアムダールが数えるのは、仕事をしている時間だ。混んでいるシステムでは、仕事が始まるまで待つ時間のほうが大きくなりうる。
リトルの法則
安定した系では、系の中にある件数の平均は、到着率と平均滞在時間の積に等しい。心得：早く終わらせたければ、始める数を減らすリトルの法則は、待ち時間を列の長さに結びつける。何が列を長くするのかが、次の問いだ。
キングマンの公式
サーバの稼働率が 100% に近づくほど、仕事がその前で待つ時間は急に伸びる。到着と処理のばらつきは、その伸びをさらに大きくする。心得：誰かが答えを待つところには、余裕を残す多くのサーバに触れるリクエストは、どこかのサーバの列や停止に出会いやすい。利用者は、いちばん遅いものを待つ。
スケールの裾野
一つのリクエストが多数のサーバに分かれると、最も遅いサーバが応答時間を決める。心得：ファンアウトでは、平均でなく遅い裾を見る裾への定番の手であるヘッジや再試行は、仕事を増やす。物事がうまくいかないときにちょうど増える仕事は、それ自体が遅さの原因になる。
一定の作業量
変更や障害の数に応じて仕事が増えるシステムは、余力がいちばん少ないときにいちばん多くの仕事をする。心得：制御系では、変化の有無に関係なく同じ量の仕事をさせるここまでの手の多くは一回きりだ。一度勝ち取った速さも、守る仕組みがなければ残らない。
ヴィルトの法則
ソフトウェアが遅くなる速さは、ハードウェアが速くなる速さを上回る。心得：ハードの進歩は、使い切らずに守る予算と考える
