スループットとレイテンシ - 日報 #143
日々色々なことが起きております。
スループットとレイテンシについて、ちょっと考える機会があったのでさわりだけ共有。
「スループットとレイテンシ」と聞くと、、、
なんだか愉快な小動物の兄弟がチーズ工場で大立ち回りをするような欧風昔話タイトルのようですが、
全く違います。
wikipediaを見てみます。
スループット
基本的な定義は、
単位時間あたりの処理能力のこと
であり、ネットワークにおいては、
単位時間あたりのデータ転送量を指す。
んだそうです。
依存するのはバスラインの抵抗とか、対応する帯域幅とかになるんでしょうか。
特に記載がないのでわかりませんね。
一方、レイテンシ
基本的な定義は、
デバイスに対して、データ転送などを要求してから、その結果が返送されるまでの遅延時間
だそうです。
データ転送とか言ってるので、スループットが深く関わってきそうですね。
でもよくわかりません。
ただ結局、スループットは「転送量」で、レイテンシは「時間」という単位みたいです。
これはどちらも「能力」の基準のように見えるのでごちゃごちゃするのかもしれません。
この掛け算を運動量のように考えることもできそうですが、
その話は一旦置いといて、
じゃぁ例えば「むちゃくちゃデカイファイルをとあるLANケーブル越しに転送して、受取側は受信し切った後に、そのファイルが正しいファイルかを判定して、その旨を返す」とします。
勿論物凄い時間がかかります。
つまり、レイテンシがとんでもなく大きいということですね。
この時、何が原因でレイテンシが高くなったのか？と言われた時、
いくつか要因が考えられます。
一番手前側から列挙していくと、
- 送信側のDisk Readがへちょい
- データ転送の速度がへちょい
- 受信側のDisk Writeがへちょい
- 受信ファイルの判定がへちょい
という感じです。
この時、2番の「データ転送の速度がへちょい」に該当するのが、
スループットと思われます。
このよくありそうな「へちょい」連鎖のうち、
僕がよく遭遇していたのが3番とか1番あたりのDisk I/Oの話でした。
正直2番に悩まされることが殆どなかったのですが、
この度2番に引っかかるという事態に遭遇し、
中々勉強になっております。
CPU的意味で負荷分散しているクラウド設計において、
スループット減少のボトルネックを発見した時は結構気持ちがなえます。
だってどんなに計算能力を向上させたとしても、
LBとサーバ間とか、VPCルータとLB間とか、
ひいてはクラウド全体の利用bpsに完全に依存してしまっているからです。
「しょぼいCPUでもいくつも並べれば凄い計算ができるんやで！」
と思っていましたが、
例えば画像のような「そこそこデカイファイル」を扱う場合は、
当たり前のようにスループットについて精密に考える必要があるわけです。
いやもう書いてて本当当たり前ですよね。
デカイ荷物運ぼうぜ！っていう目標をたてて、
すごい沢山人数集めたけど、
運ぶ道が細くて渋滞してたら、何の意味もないもんね。
いやもう、
なんか1個1個ですね、、、
