Categorygithub.com/momotaro98/go-codes-for-learningConcurrency-in-Gochapter4_Patterns_of_Go_Concurrencysection11_queue
# README
4.11 Queue
キューがシステム全体の性能を向上させうる状況を分析していってみましょう。これが当てはまる状況は次の2つだけです。
- ステージ内でのバッチによるリクエストが時間を節約する場合
- ステージにおける遅延がシステムにフィードバックループを発生させる場合
ステージにおける遅延がシステムにフィードバックループを発生させる場合
2つ目のシナリオは1つ目よりも重要です。その理由は、この状況は上流のシステムを全体的に崩壊させる可能性があるからです。
これはパイプラインと上流のシステムの間に再帰的な関係がある場合に発生します。たとえば上流のステージやシステムが送信する新しいリクエストの割合がパイプラインの効率になんらかの形で影響している場合です。
パイプラインの効率が一定の致命的な閾値を下回った場合には、パイプラインの上流のシステムはパイプラインへの入力値を増やし始め、それによってパイプラインの効率が悪くなり、デススパイラルが始まります。
パイプラインの入り口にキューを導入することで、リクエストに対する時間差を発生させる代わりにフィードバックループを崩します。
リトルの法則
- L = システムの平均ユニット数 [個数]
- λ = ユニットの平均の到達率 [個数/時間]
- W = ユニットのシステム内での平均滞在時間 [時間]
L = λ ΣiWi
これはパイプラインが最も遅いステージに律速になるということに言い換えです。どこもかしこも最適化しなければなりません!
↑なに言っているか不明
病院の滞在時間に置き換える
W = L / λ
W: 待ち時間 (予想) L: 行列に並んでいる人 λ: 時間あたりにやってくる人の数
まとめ
キューはシステム内で便利ですが、その複雑さゆえに、私はふだん実装する際には最適化の最後の手段として提案します。