Latency vs Throughput

နားလည်ထားရမယ့် အချက်

Latency နှင့် throughput ဆိုတာ ဆင်တူပေမယ့် တကယ်တော့ မတူညီတဲ့ အရာနှစ်ခုကို တိုင်းတာတာဖြစ်ပြီး တစ်ခုကို improve လုပ်တာက တစ်ခြားတစ်ခုကို တိတ်တဆိတ် ထိခိုက်စေနိုင်ပါတယ်။ Latency ဆိုတာ request တစ်ခု အစကနေ အဆုံးထိ ဘယ်လောက်ကြာလဲ — user တစ်ယောက်က response တစ်ခုအတွက် စောင့်ရတဲ့ အချိန်ပါ။ Throughput ဆိုတာ system က user အားလုံးပေါင်းပြီး တစ်စက္ကန့်မှာ request ဘယ်လောက် ပြီးမြောက်အောင် လုပ်ပေးနိုင်လဲပါ။ Batching ဆိုတာ ဒီနှစ်ခု ပဋိပက္ခဖြစ်တဲ့ နေရာအထင်ရှားဆုံးပါ — database write 100 ကို batch တစ်ခုအဖြစ် စုစည်းလိုက်ရင် throughput ကို သိသိသာသာ တိုးတက်စေပေမယ့် (round trip နည်းသွား၊ တစ်စက္ကန့်ကို total work ပိုများသွား) individual write တစ်ခုချင်းစီကတော့ batch ပြည့်တဲ့အထိ စောင့်ရလို့ latency ပိုကြာသွားပါတယ်။ latency ကို ဘယ်လိုတိုင်းတာမလဲဆိုတာလည်း အရေးကြီးပါတယ် — average က မှားနိုင်ပါတယ်၊ ဘာကြောင့်ဆိုတော့ အလွန်နှေးတဲ့ request အနည်းငယ်ကို မြန်တဲ့ request အများကြီးက ပျဉ်းညီစေတတ်လို့ပါ။ Percentile တွေက ဒါကို ပြင်ပေးပါတယ် — p50 (median) က typical experience ကို ပြပြီး p95 က user ရဲ့ 5% ပိုနှေးတဲ့ အုပ်စု ဘာတွေ့ကြုံရလဲ ပြသလို p99 ကတော့ အဆိုးဆုံး 1% ကို ပြသပါတယ်။ p50 = 50ms ဆိုရင် ကောင်းလွန်းသလို ကြားရပေမယ့် p99 က 3 စက္ကန့်ဆိုရင် request 100 ခုမှာ 1 ခုက သုံးလို့မရလောက်အောင် နှေးတယ်လို့ ဆိုလိုပြီး request သန်းချီရှိတဲ့ scale မှာဆိုရင် ဒီ 'ရှားပါးတဲ့' 1% ဟာ real people အများကြီး စိတ်ပျက်ရမယ့် ဂဏန်းကြီးတစ်ခု ဖြစ်နေတာပါ။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Tutorial Platform ကြီးထွားလာတာနဲ့အမျှ engineer တွေဟာ dashboard ပေါ်က 'average response time' ကိုပဲ ကြည့်ပြီး healthy လို့ ပြောလို့မရတော့ပါဘူး — 80ms ဆိုတဲ့ လှပတဲ့ average တစ်ခုနောက်မှာ connection နှေးတဲ့ learner တွေ ဒါမှမဟုတ် cache cold ကျတဲ့ request တွေဟာ p99 မှာ 4 စက္ကန့် စောင့်နေရတာ ဖုံးကွယ်နေနိုင်ပါတယ်။ lesson loading ဒါမှမဟုတ် search-suggest လို endpoint တွေအတွက် p50/p95/p99 ကို track လုပ်ခြင်းက average metric ကောင်းနေချိန်မှာတောင် learner အစုအဖွဲ့တစ်ခု ဒုက္ခရောက်နေတာကို team က မြင်စေနိုင်ပါတယ်။ ဒီကွာခြားချက်နဲ့ batching trade-off ဟာ design choice တစ်ခုက platform ကို 'ပိုမြန်' စေတယ်လို့ ဆိုတိုင်း ဒီ course တစ်လျှောက်လုံးမှာ ပြန်ပေါ်လာမှာပါ။

• Latency = request တစ်ခု ကြာချိန်; throughput = တစ်စက္ကန့်ကို ပြီးမြောက်တဲ့ request အရေအတွက် — axis နှစ်ခုကွဲပြားပြီး trade-off ဖြစ်နိုင်တယ်။
• Batching ဆိုတာ throughput ရဖို့ latency ကို ဖလှယ်တဲ့ classic trade-off တစ်ခုဖြစ်ပြီး တစ်စက္ကန့်ကို total work ပိုများသွားသော်လည်း request တစ်ခုချင်းစီကို နှောင့်နှေးစေတယ်။
• Average မဟုတ်ဘဲ percentile (p50/p95/p99) ကသာ request အနှေးဆုံးတွေရဲ့ တကယ့်ခံစားမှုကို ဖော်ပြနိုင်တယ် — average ကတော့ မြန်တဲ့ request အများကြီးက ပျဉ်းညီသွားစေတတ်တယ်။

အတူတူ စမ်းရေးကြည့်မယ်

Request count
   ^
   |        ___
   |      _/   \_
   |    _/       \___
   |  _/              \________
   | /                          \________________
   |/_________________________________________________\____> latency (ms)
        ^p50            ^p95              ^p99
        50ms             400ms             3000ms

  Most requests cluster fast (near p50) --
  but the tail stretches far right: p99 is 60x slower than p50.

Diagram က latency distribution ကို ပြသပြီး p50 က မြန်နေချိန်မှာတောင် p99 ဟာ မည်မျှ ဝေးကွာစွာ နှေးနိုင်လဲဆိုတာကို ဖော်ပြပါတယ်။

Wikipedia — Latency (engineering) — System Design