Calm Hill My Random Thoughts

Capacity Estimation and Queueing Model

Fri 21 April 2017

Server တွေနဲ့ အလုပ်လုပ်တဲ့လူတိုင်း Server ဟာ Loading Capacity ဘယ်လောက် အများဆုံးအနေနဲ့ ခံနိုင်မလဲဆိုတဲ့ မေးခွန်းတခုက မကြာခဏ အမေးခံရတယ်။ ဒီမေးခွန်းဟာ ခန့်မှန်းပြီးဖြေရတာဖြစ်ပြီး အများအားဖြင့်က ကိုယ်မြင်ခဲ့ဖူးတဲ့ အမြင့်ဆုံးဖြစ်ခဲ့တဲ့ Loading အပေါ်ကိုအခြေခံပြီး ၁ မိနစ်မှာ Concurrent Clients 100, 1000, 5000, 10000, … စသည်ဖြင့် ဖြေကြတာရှိတယ်။ ၁ မိနစ်မှာ Concurrent ၁၀၀ ဆိုတာ ဘယ်လိုဟာကို ပြောချင်တာလဲ Concurrent ဆိုတဲ့ စကားလုံးက တကယ်ပဲသုံးလို့ရလို့ Client ၁၀၀ အပြိုင်သုံးတာ ၁ မိနစ်အထိ ခံနိုင်တယ်လို့ ပြောချင်တာလား ၁ မိနစ်အတွင်းမှာ Client ၁၀၀ ကို Serve လုပ်နိုင်လို့ ပြောချင်တာလား Client ၁၀၀ က ၁ မိနစ်အတွင်း ဘယ်လိုဝင်လာမှာလဲ ၀.၆ စက္ကန့်ကို Client ၁ ခုအနေနဲ့ ဝင်လာတာကို ခံနိုင်တာလား ဝုန်းဆိုပြီးတော့ ၁၀၀ ဝင်လာတာကို ၁ မိနစ်အတွင်း ရှင်းပေးနိုင်တာလား အမေးခံရတဲ့အခါ မြင်ဖူးကြုံဖူးတာကို အခြေခံပြီးဖြေထားမိရင် ရှင်းမပြနိုင်တော့ အတော်ဂွကျတယ်။

ခဏခဏလည်း စကားများရ လွဲလွန်းတာလည်း ခဏခဏဖြစ်လာတော့ နောက်ပိုင်းတော့ Loading ကိစ္စမေးလာရင် ချက်ချင်းမဖြေတော့ဘူး လိုချင်တဲ့ Requirements ကိုပြော အာမခံနိုင်မယ့် Specification ကို ပြန်ပြောမယ်လို့ဖြေပြီး နောက်မှပဲ စာရင်းစာတမ်းနဲ့ လိုအပ်တာတွေ ပြန်ပြောဖြစ်တော့တာ အတော်ကြာပါပြီ။ အခုကတော့ အမေးအခံရဆုံး မေးခွန်းတွေ Requirements တွေအပေါ် မူတည်ပြီးတော့ သိပ်ပြီးတော့မရှုပ်ထွေးတဲ့ Queueing Model တခုနဲ့ တွက်ကြည့်ပြီးတော့ Loading ခံနိုင်ရည်ကို ဘယ်လိုအခြေအနေအောက်မှာ အာမခံနိုင်တယ်ကို နမူနာစမ်းကြည့်ပြီး ခန့်မှန်းကြည့်ကြတာပေါ့။

အမြဲတမ်းလိုလို Server Loading လို့ဆိုတာနဲ့ ခေါင်းထဲကို ရောက်လာတာက ဆံပင်ညှပ်ဆိုင်ကို နမူနာပြပြထားတဲ့ သင်္ချာမှာသင်ရတဲ့ Queueing Model တွေပဲ။ Queueing မှာ Service ပေးမယ့် Server ရယ် Service ကိုလာသုံးမယ့် Customer တွေရောက်လာနိုင်တဲ့နှုံး Arrival Rate \(\lambda\) ရယ် Service ကို ဘယ်လောက်ကြာအောင် Customer တယောက် သုံးနိုင်လဲကိုအခြေခံတဲ့ Service Rate \(\mu\) ရယ်ကို အခြေခံပြီးတော့ ယေဘုယျအားဖြင့် Server ဘယ်လောက် အလုပ်ရှုပ်နေမှာလဲဆိုတဲ့ Utilisation \(\rho\) တို့ Customer တွေအနေနဲ့ Service ကိုသုံးဖို့အတွက် အချိန်ဘယ်လောက်ကြာအောင် စောင့်ရမှာလဲ \(W_q\), \(W\) တို့ အချိန်တခုတွင်းမှာ Customer ဘယ်လောက် Server ထဲမှာရှိနေလဲ \(L_q\), \(L\) စသည်ဖြင့်တွေကို ခန့်မှန်းကြည့်ကြတာပေါ့။ Server တွေကို ကိုယ်သုံးမယ့် Web Server တွေ Customer တွေကို Client Connections တွေလို့ ယူဆလိုက်ရင် Queueing Model တွေဟာ ရှင်းချင်တဲ့ပြဿနာနဲ့ အတော်နီးစပ်တယ်။

M/M/1 Queue

$$\rho=\frac{\lambda }{\mu}$$
$$L_q=\frac{\rho^2}{1-\rho}$$
$$W_q=\frac{L_q}{\lambda}$$
$$W=W_q+\frac{1}{\mu}$$
$$L=\lambda W$$
  • Numbers of Client in the Queue = \(L_q\)
  • Numbers of Client in the System = \(L\)
  • Waiting time in the Queue = \(W_q\)
  • Waiting time in the System = \(W\)

အလွယ်ဆုံးအနေနဲ့ API Server ၁ လုံးရယ် Server ကိုလာပြီးသုံးကြမယ် Client Requests တွေ အနေနဲ့ စဉ်းစားကြည့်ရအောင် Server တလုံးထဲအတွက် သုံးလို့အဆင်ပြေတဲ့ M/M/1 Queueing Model မှာသုံးတဲ့ Equations တွေကို အပေါ်မှာပြထားတယ်။ Equations တွေမှာ အချိန်အတိုင်းအတာ တခုအတွင်းမှာ ရောက်လာနိုင်တဲ့ Request အရေအတွက် \(\lambda\) နဲ့ Server ရဲ့ Request တခုအတွက် အချိန်ဘယ်လောက်ကြအောင် အလုပ်လုပ်ပေးရလဲဆိုတဲ့ \(\mu\) ကို သိတယ်ဆိုရင် အချိန်အတိုင်းအတာ တခုအတွင်းမှာ Request ဘယ်လောက် အများဆုံး \(L\) ဘယ်လောက်ရယ် Request တခုအတွက် Response Time ဘယ်လောက်ဆိုတာ အလွယ်တကူ တွက်လို့ရတယ်။

ဥပမာအနေနဲ့ Request တခု အလုပ်ပေးဖို့အတွက် API Server က ၅၀ မီလီစက္ကန့် ကြာအောင် အလုပ်လုပ်ရပြီးတော့ Server ကို ယေဘုယျအားဖြင့် ၁ စက္ကန့်မှာ Request ၁၅ ခုလောက် လာလေ့ရှိတယ်ဆိုပါစို့။ Request တခုကို ၅၀ မီလီစက္ကန့် ကြာတယ်ဆိုတော့ ၀.၀၅ စက္ကန့်ကြာတယ် Service Rate \(\mu\) က အချိန်မဟုတ်ဘူး အချိန်တခုအတွင်းမှာ လုပ်ပေးနိုင်မယ့် အရေအတွက်ဆိုတော့ \(\mu=1/0.05=20\) requests/second ရတယ် ၁ စက္ကန့်မှာ Request ၁၅ ခု ရောက်နိုင်တယ်ဆိုတော့ \(\lambda=15\) requests/second ရှိတယ်။ အဲဒါဆိုရင် \(\rho=0.75\), \(L_q=2.25\), \(W_q=0.15\), \(W=0.2\) ဆိုတော့ Server ဟာ ၇၅% အလုပ်ရှုပ်နေမယ် Request တခုအတွက် စောင့်ရမယ့်အချိန်က ၀.၁၅ စက္ကန့်နဲ့ အစအဆုံးပြီးဖို့ ၀.၂ စက္ကန့်ကြာနိုင်တယ်လို့ ခန့်မှန်းလို့ရတယ်။

ဥပမာမှာ Request တခုအတွက် အစအဆုံးကြာချိန်ဟာ ၀.၂ စက္ကန့် ရှိတယ်ဆိုတာကို သတိထားမိရင် Request တခုကို ၀.၀၅ စက္ကန့်ဆိုတော့ ၁ စက္ကန့်မှာ Request အခု ၂၀ ကို ၀.၀၅ စက္ကန့်နှုံးနဲ့ လုပ်နိုင်တယ်လို့ အလွယ်တွက်တာနဲ့ အရမ်းကွာနေတာ တွေ့ရလိမ့်မယ် ဒီကွာခြားချက်ဟာ သတိထားရမယ့်အချက်ပါ။ လူအများစုဟာ အဲဒီနည်းနဲ့ပဲ ခန့်မှန်းကြပြီးတော့ အမြင့်ဆုံးခံနိုင်ရည်အထိ စမ်းကြည့်တဲ့အချိန်မှာ ခန့်မှန်းထားတာ အတော်ကွာတဲ့အတွက် Server Down သွားဖို့များပါလိမ့်မယ်။ စုစုပေါင်းကြာချိန် ၀.၂ စက္ကန့်လို့ ခန့်မှန်းထားတာကို ရှိတယ်ဆိုရင် API Server မှာ Request Timeout လို Config တွေမှာ Timeout ကို ၀.၂ ထက်နည်းအောင် ပေးလို့မရဘူး ဆိုတာမျိုးလည်း သတိထားလို့ရတာပေါ့ ဆက်ပြီးတော့ စဉ်းစားကြည့်မယ်ဆိုရင် တခြားအသုံးတည့်နိုင်တဲ့ နေရာတွေလည်း ရှိဦးမှာပေါ့လေ။

Equations တွေမှာပါတဲ့ Dependent Variables တွေကို တွက်ယူတာရယ် အသုံးဝင်တာရယ် ပြောပြီးတဲ့အခါ အရေးအကြီးဆုံး Independent Variables တွေ ဖြစ်တဲ့ \(\mu\) နဲ့ \(\lambda\) တွေ အကြောင်းပြောရမယ်။ လက်တွေ့မှာ အဲဒီတန်ဖိုးတွေ အနီးစပ်ဆုံး အမှန်ရဖို့ဆိုတာက သိပ်ပြီးတော့မလွယ်ဘူး Empirically တိုင်းကြည့်မှရတယ်။ Service Rate \(\mu\) အတွက် Request တခုအတွက် ကြာချိန်သိဖို့အတွက် သတ်မှတ်ထားတဲ့ Hardware Specs တခုအပေါ်မှာ ကိုယ့်ရဲ့ API Server မှာရှိတဲ့ API တွေရဲ့ ကြာချိန်တွေကို Profile လုပ်ထားတာကို အခြေခံပြီးတော့မှ တကယ်သုံးမယ့် Hardware Specs အတွက်ကို ခန့်မှန်းယူရတယ်။ အဲဒီမှာ ကြာချိန်ဆိုတာက API Server မှာ Multiple API တွေရှိမှာပဲဆိုတော့ ကြာချိန်တွေကလည်း တခုနဲ့တခုတူမှာမဟုတ်ဘူး အချိန်သိပ်မကွာခြားရင် Mean နဲ့သုံးလို့ရပေမယ့် အချိန်အရမ်းကြာတဲ့ API တွေပါမယ်ဆိုရင် Mean နဲ့သုံးရတာ အဆင်ပြေချင်မှပြေမယ် Data တွေရဲ့ Statistics အပေါ်မူတည်ပြီးတော့ ကိုယ့်အတွက် ဘယ်တန်ဖိုးက Estimation အတွက် အသင့်လျော်ဆုံးဖြစ်မလဲ စဉ်းစားစရာတွေရှိတယ်။ Request Rate \(\lambda\) ကလည်း Production မှာ တကယ်တမ်း သုံးနေတာမဟုတ်ရင် အမှန်ကိုဘယ်လိုမှ မသိနိုင်ဘူး လိုချင်တဲ့ Requirement ရယ် ရည်ရွယ်ထားတဲ့ Hardware Specs ပေါ်က \(\mu\) ရယ်ကို အခြေခံပြီးတော့ ခန့်မှန်းပေးရတာရှိသလို Request Rate ဟာ Requirement တခုအနေနဲ့ ပါလာတာဆိုရင်လည်း အဲဒီအပေါ်မူတည်ပြီး လိုအပ်တဲ့ \(\mu\) ရဖို့အတွက် Hardware Specs ကို ခန့်မှန်းပြီးတော့ တောင်းယူရတဲ့ အခါမျိုးလည်းရှိတယ်။

အပေါ်မှာပြောခဲ့တာတွေက Server တလုံးကို နမူနာအနေနဲ့ M/M/1 ကိုသုံးပြီးတော့ Estimation လုပ်ကြည့်တာပါ နေရာတိုင်း အသုံးတည့်တယ်လို့ မဆိုလိုပါဘူး။ M/M/1 က Server ၁ လုံးအတွက်ပဲ သုံးလို့ရတယ် ၁ လုံးထက်ပိုရင်လည်း M/M/c လို Model တွေနဲ့ စမ်းကြည့်လို့ရတယ် Server ဆိုတာကလည်း Physical Machine တခု ဖြစ်ချင်မှဖြစ်မယ် Process အရေအတွက်တို့ Processor Core အရေအတွက်တို့လည်း ဖြစ်နိုင်တဲ့အတွက် လက်တွေ့ကိစ္စ အတော်များများမှာ M/M/1 ထက် M/M/c ပဲ ပိုအသုံးများနိုင်တယ်။ စောင့်နေရမယ့် Request အရေအတွက် အကန့်အသတ်တွေတို့ Server တွေက ညီတူညီမျှ အလုပ်လုပ် မလုပ်တာတွေတို့ ပါလာမယ်ဆိုရင်တော့ တခြား Queueing Model တွေသုံးမှရမယ်။ နောက်တခုက M/M/1 မှာ \(\lambda\) က အချိန်တခုတွင်းမှာ ရောက်လာနိုင်တဲ့ Request အရေအတွက်လို့ပဲဆိုတယ် Random အနေနဲ့က Poisson process နဲ့ပဲဝင်လာပါတယ်။ ကိုယ့်ရဲ့ Request တွေ ရောက်လာနိုင်တာက Poisson process နဲ့ သိပ်ပြီးတော့ လွဲနေတယ်ဆိုရင် အတော်ပြဿနာရှိလိမ့်မယ်။ စိတ်ဝင်စားတယ်ဆိုရင် တခြား Queueing Model တွေကို စမ်းကြည့်ပေါ့ References ထဲမှာလည်း အသုံးတည့်နိုင်တဲ့ Link တချို့ပြထားတယ်။

မသိကိန်းတွေရယ် Random Simulation တွေ အရမ်းများတဲ့အတွက် ဘယ်လိုပဲစနစ်တကျ ခန့်မှန်းပြီးဖြေဖြေ အနည်းနဲ့အများ မှားတာကတော့ မှားကြမှာပါ ဒါပေမယ့် ကိုယ့်မှာခန့်မှန်းတဲ့ အခြေခံနည်းစနစ် တိတိကျကျ ရှိတယ်ဆိုရင် ကိုယ့်ကိုပြန်မေးရင်လည်း အသေအချာဖြေနိုင်ဖို့ရယ် Customer လိုအပ်တဲ့ တကယ့် Requirement က ကိုယ်တကယ်တမ်း အာမခံသင့်လား မခံသင့်ဘူးလား ကြိုတင်ပြီး သုံးသပ်ဖို့အတွက်က အတွေ့အကြုံတခုထဲကို ယုံပြီးတော့ပြောတာထက် ပိုပြီးတော့စိတ်ချရတယ် အငြင်းအခုံဖြစ်လာတဲ့အခါ တကယ်အာမမခံထားတဲ့ အကြောင်းအရာမျိုးနဲ့ မှားလာတဲ့အခါ တာဝန်မရှိကြောင်း ငြင်းလို့ရတာပေါ့။ Queueing နဲ့က လွယ်လည်းလွယ်သလို Estimation ဆိုတော့ မှားတယ်ဆိုတောင် လက်ခံနိုင်တဲ့ အတိုင်းအတာ တခုအတွင်းက ဖြစ်နေတာကြောင့် ရှုပ်ရှုပ်ထွေးထွေး သိပ်လုပ်နေရင်လည်း မတန်ဘူးလို့ယူဆလို့ ဥပမာအဖြစ် အပျင်းပြေ စမ်းကြည့်တာပါ တခြား Stochastic Model တွေလည်း သုံးလို့ရနိုင်တာပါပဲ။

References

  • https://en.wikipedia.org/wiki/M/M/1_queue
  • http://web.mst.edu/~gosavia/queuing_formulas.pdf
  • http://irh.inf.unideb.hu/~jsztrik/education/16/SOR_Main_Angol.pdf
  • http://www.supositorio.com/rcalc/rcalclite.htm
Category: ကြံသည်ဖန်သည်