スループット(Throughput)とレイテンシー(Latency)

この2つのことをよく理解することは、バックエンドソフトウェアシステムの容量や性能に関連することを効果的に考え、議論し、計画するために大いに役立ちます。

しかし、この2つの概念に関する古くからの神話は、いまだに根強く残っており、リトルの法則のような明確な理論をもってしても、なかなか払拭することができません。

そこで、この記事ではイラストを用いて、この2つの概念をより直感的な方法で簡単に説明します。

スループット(Throughput)とは

「時間あたりの処理能力」
一回の処理でどのぐらいのデータを送ったりできるか、という指標。
高ければ高いほど性能が良いということになる。
ただし、あんまりにも一度にたくさんのデータを送ると、レイテンシー(Latency)が低くなる。

レイテンシー(Latency)とは

「通信の遅延時間」(要求してから応答が返るまでの時間)
数え方は「低い（良い）」か「高い（悪い）」。
Webオンラインシステムやスマホゲームなどは通信の度に何秒も待たされるとものすごいストレスになるので、そういう場合はスループットよりもレイテンシーが重視される。

TPS(Transaction per second)

システムによって1秒間に完了したトランザクションの数

イラストを用いた概念の理解

このイラストでは、水滴がAからBまでの3つのパイプセクションを通過することで、あるトランザクションを表現しています。
パイプセクションは、トランザクションの一部である「プロセス」、または「リソース」と見なすことができます。システムは6つのフェーズを経て、それぞれのフェーズで水の流量(スループット)（T1〜T6で表される）(※Tは、Throughputを指す)が増加する。

水滴がA地点からB地点に移動するまでの経過時間が、このトランザクションの応答時間または遅延時間(レイテンシー）（L1〜L6）(※Lは、Latencyを指す)である。つまり、スループットT1〜T6の6つのフェーズすべてについて、それぞれL1〜L6のLatency（所要時間）に対応する値が存在することになります。

このアニメーションは、概念をより直感的に理解するためのメタファーに過ぎないことに注意してください。

このイラストを見ることで、以下のような結論を導き出すことができます。

L1 ≈ L2 ≈ L3 while T3 > T2 > T1

必要なシステムリソースのいずれもが完全に占有されていない限り、Latencyは、フェーズ１からフェーズ３まで同じように維持されます。この場合、スループット（TPS、Transactions Per Second）が高いほど、利用可能なリソースをより効率的に使用することができます。

平均レイテンシはPhase-4から増加

T4のようにスループットがP2の能力を超えた場合、トランザクションはP1のプロセスでP2を待つキューに入れられ、結果として待ち時間が長くなります。

P2は、このシステムの「ボトルネック」と特定

なぜなら、P1のフローキャパシティ（またはスループット）がP2のフローキャパシティより大きいからです。また、P2がP3のキャパシティを効率的に処理できないため、システムがビジー状態でもリソースP3はたくさんアイドルすることになる。

負荷が高い状態が続くと、"タイムアウト "が発生

システムのスループット（または負荷）がP2の流量容量（T4～T6）よりも高く、十分に長い時間続くと、AからBへ移動する水が予想以上に時間を要する「タイムアウト」が発生し始める。

ローカルのキューが満杯になると、トランザクションの呼び出しが即座に失敗

スループットレートがP2のフローキャパシティを超える時間が十分に長いと、Point Aのキューもオーバーフローし、トランザクションは事実上即座に失敗することになる。

参考文献