ကျွန်တော်တို့က နည်းပညာအကြောင်း ဆွေးနွေးခဲ့ပါတယ်။ ဆောင်းပါး၊ ဤတစ်ခုတွင် ကျွန်ုပ်တို့သည် HTTPS ကို စမ်းသပ်သော်လည်း ပိုမိုလက်တွေ့ကျသော အခြေအနေများတွင်။ စမ်းသပ်ရန်အတွက်၊ ကျွန်ုပ်တို့သည် Let's Encrypt လက်မှတ်ကို ရရှိပြီး Brotli ချုံ့မှုကို 11 သို့ ဖွင့်ထားသည်။
ဤတစ်ကြိမ်တွင် ကျွန်ုပ်တို့သည် VDS ပေါ်တွင် ဆာဗာတစ်ခု သို့မဟုတ် စံပရိုဆက်ဆာတစ်ခုရှိ host တစ်ခုပေါ်တွင် virtual machine အဖြစ်အသုံးပြုခြင်း၏ဇာတ်လမ်းကို ပြန်လည်ထုတ်လုပ်ရန်ကြိုးစားပါမည်။ ဤရည်ရွယ်ချက်အတွက်၊ ကန့်သတ်ချက်ကို သတ်မှတ်ထားသည်-
- 25% - ကြိမ်နှုန်း ~ 1350 MHz နှင့် ညီမျှသည်။
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
တစ်ကြိမ်ချိတ်ဆက်မှုအရေအတွက် 500 မှ 1၊ 3၊ 5၊ 7 နှင့် 9၊
ရလဒ်များ -
နှောင့်နှေးမှုများ
HTTPD Tools သည် တောင်းဆိုချက်တစ်ခုစီအတွက် အသုံးပြုသူအသစ်ကို ဖန်တီးပေးသောကြောင့် TTFB ကို သီးခြားစမ်းသပ်မှုတစ်ခုအဖြစ် အတိအကျထည့်သွင်းထားပါသည်။ အသုံးပြုသူသည် စာမျက်နှာအချို့ကို နှိပ်နေဆဲဖြစ်ပြီး လက်တွေ့တွင် TTFP သည် အဓိကအခန်းကဏ္ဍမှပါဝင်နေသောကြောင့် ဤစမ်းသပ်မှုသည် လက်တွေ့နှင့်အတော်လေးကွာနေပါသည်။
ပထမဆုံး၊ ယေဘုယျအားဖြင့် IIS virtual machine ၏ပထမဆုံးစတင်ပြီးနောက် ပထမဆုံးတောင်းဆိုမှုသည် ပျမ်းမျှ 120 ms ကြာသည်။
နောက်ဆက်တွဲတောင်းဆိုမှုအားလုံးသည် TTFP ၏ 1.5 ms ကိုပြသသည်။ Apache နှင့် Nginx တို့သည် ဤကိစ္စတွင် နောက်ကျကျန်နေပါသည်။ ကိုယ်တိုင်ကိုယ်ကျ၊ စာရေးသူသည် ဤစမ်းသပ်မှုကို အထင်ရှားဆုံးဟု မှတ်ယူထားပြီး ၎င်းကိုအခြေခံ၍ အနိုင်ရသူကိုသာ ရွေးချယ်မည်ဖြစ်သည်။
IIS ကက်ရှ်များသည် တည်ငြိမ်သောအကြောင်းအရာကို ချုံ့ထားပြီးဖြစ်ပြီး ၎င်းကိုဝင်ရောက်သည့်အခါတိုင်း ၎င်းကိုချုံ့မပေးသည့်အတွက် ရလဒ်မှာ အံ့သြစရာမဟုတ်ပါ။
ဖောက်သည်တစ်ဦးစီ သုံးစွဲသည့်အချိန်
စွမ်းဆောင်ရည်ကို အကဲဖြတ်ရန်၊ ချိတ်ဆက်မှု တစ်ခုတည်းဖြင့် စမ်းသပ်မှုတစ်ခုသည် လုံလောက်သည်။
ဥပမာအားဖြင့်၊ IIS သည် စက္ကန့် 5000 အတွင်း အသုံးပြုသူ 40 ၏ စမ်းသပ်မှုကို ပြီးမြောက်ခဲ့ပြီး၊ ၎င်းသည် တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 123 ခုဖြစ်သည်။
အောက်ပါဂရပ်များသည် ဝဘ်ဆိုက်အကြောင်းအရာကို လုံးဝလွှဲပြောင်းပြီးသည်အထိ အချိန်ကိုပြသသည်။ ၎င်းသည် သတ်မှတ်အချိန်အတွင်း ပြီးမြောက်သည့် တောင်းဆိုမှု အချိုးအစားဖြစ်သည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ တောင်းဆိုချက်အားလုံး၏ 80% ကို IIS တွင် 8ms နှင့် Apache နှင့် Nginx တွင် 4.5ms ဖြင့် လုပ်ဆောင်ပြီး Apache နှင့် Nginx တွင် တောင်းဆိုချက်အားလုံး၏ 8% ကို 98 မီလီစက္ကန့်အထိ ကြားကာလတစ်ခုအတွင်း ပြီးမြောက်ခဲ့သည်။
တောင်းဆိုချက် 5000 ကို စီမံဆောင်ရွက်ခဲ့သည့် အချိန်-
တောင်းဆိုချက် 5000 ကို စီမံဆောင်ရွက်ခဲ့သည့် အချိန်-
သင့်တွင် 3.5GHz CPU နှင့် 8 cores ရှိသော virtual machine တစ်ခုရှိပါက၊ ထို့နောက် သင်အလိုရှိသောအရာကို ရွေးချယ်ပါ။ ဤစမ်းသပ်မှုတွင် ဝဘ်ဆာဗာများအားလုံးသည် အလွန်ဆင်တူပါသည်။ အောက်မှာ host တစ်ခုစီအတွက် ဘယ်ဝဘ်ဆာဗာကို ရွေးရမလဲဆိုတာကို ပြောပြပါမယ်။
အနည်းငယ် ပိုလက်တွေ့ကျသည့် အခြေအနေသို့ရောက်သောအခါ၊ ဝဘ်ဆာဗာများအားလုံး ခေါင်းချင်းဆိုင်သွားကြသည်။
throughput:
တစ်ပြိုင်နက်ချိတ်ဆက်မှုအရေအတွက်နှင့် နှောင့်နှေးမှုဂရပ်ဖစ်။ ပိုချောပြီး အောက်ပိုင်းက ပိုကောင်းပါတယ်။ နောက်ဆုံး 2% သည် ၎င်းတို့ကို ဖတ်၍မရနိုင်သောကြောင့် ဇယားများမှ ဖယ်ရှားခဲ့သည်။
ယခု server ကို virtual hosting တွင်လက်ခံကျင်းပသည့်ရွေးချယ်မှုကိုစဉ်းစားကြည့်ရအောင်။ 4 GHz တွင် 2.2 cores နှင့် 1.8 GHz တွင် core တစ်ခုယူကြပါစို့။
စကေးနည်း
vacuum triodes၊ pentodes စသည်တို့၏ လက်ရှိ-ဗို့အား လက္ခဏာများကို သင်မြင်ဖူးပါက၊ ဤဂရပ်များသည် သင့်အတွက် ရင်းနှီးပါလိမ့်မည်။ ဤအရာသည် ကျွန်ုပ်တို့ ဖမ်းရန် ကြိုးပမ်းနေသည် - ရွှဲသည်။ ကန့်သတ်ချက်မှာ သင် cores မည်မျှပင် ပစ်ချသောအခါတွင် စွမ်းဆောင်ရည် တိုးလာသည်ကို သိသာမည်မဟုတ်ပေ။
ယခင်က၊ စိန်ခေါ်မှုတစ်ခုလုံးသည် တောင်းဆိုချက်အားလုံးအတွက် အနိမ့်ဆုံး latency ဖြင့် တောင်းဆိုမှုများ၏ 98% ကို လုပ်ဆောင်ရန်ဖြစ်ပြီး မျဉ်းကွေးကို တတ်နိုင်သမျှ ပြားအောင်ထားရန်ဖြစ်သည်။ ယခု၊ အခြားမျဉ်းကွေးတစ်ခုကို တည်ဆောက်ခြင်းဖြင့်၊ ဆာဗာတစ်ခုစီအတွက် အကောင်းဆုံးလုပ်ဆောင်မှုအမှတ်ကို ကျွန်ုပ်တို့ ရှာဖွေပါမည်။
ဒါကိုလုပ်ဖို့၊ Requests per second (RPR) ညွှန်ကိန်းကို ယူလိုက်ကြရအောင်။ အလျားလိုက်သည် ကြိမ်နှုန်းဖြစ်သည်၊ ဒေါင်လိုက်သည် တစ်စက္ကန့်လျှင် လုပ်ဆောင်ခဲ့သော တောင်းဆိုမှုအရေအတွက်ဖြစ်ပြီး လိုင်းများသည် core အရေအတွက်ဖြစ်သည်။
Nginx သည် တစ်ခုပြီးတစ်ခု တောင်းဆိုမှု မည်မျှ ကောင်းမွန်ကြောင်း ဆက်စပ်မှုကို ပြသသည်။ ဤစမ်းသပ်မှုတွင် 8 cores သည် ပိုမိုကောင်းမွန်သည်။
ဤဂရပ်သည် core တစ်ခုတွင် Nginx မည်မျှပိုကောင်းသည် (မများပါ) မည်မျှအလုပ်လုပ်သည်ကို ရှင်းလင်းစွာပြသသည်။ သင့်တွင် Nginx ရှိပါက၊ သင်သည် static များကိုသာ hosting လုပ်ပါက cores အရေအတွက်ကို တစ်ခုသို့လျှော့ချရန် စဉ်းစားသင့်သည်။
IIS သည် Chrome ရှိ DevTools အရ အနိမ့်ဆုံး TTFB ပါသော်လည်း၊ Apache Foundation မှ stress test နှင့် ပြင်းထန်သော တိုက်ပွဲတွင် Nginx နှင့် Apache နှစ်ခုလုံးကို ဆုံးရှုံးနိုင်သည်။
ဂရပ်များ၏ ကွေးညွှတ်မှုအားလုံးကို သံထည်များဖြင့် ပြန်လည်ထုတ်လုပ်ထားသည်။
ကောက်ချက်တစ်မျိုးမျိုး၊
ဟုတ်ကဲ့၊ Apache သည် 1 နှင့် 8 cores တွင် ပိုဆိုးသော်လည်း 4 တွင် အနည်းငယ်ပိုကောင်းသည်။
ဟုတ်ကဲ့၊ 8 cores ပေါ်ရှိ Nginx သည် 1 နှင့် 4 cores တွင် တစ်ခုပြီးတစ်ခု ပိုမိုကောင်းမွန်သော တောင်းဆိုမှုများ လုပ်ဆောင်ပြီး ချိတ်ဆက်မှုများစွာရှိသည့်အခါ ပိုဆိုးသည်။
ဟုတ်ကဲ့၊ IIS သည် Multi-threaded workloads အတွက် 4 cores ကို နှစ်သက်ပြီး single-threaded workloads အတွက် 8 cores ကို နှစ်သက်သည်။ အဆုံးစွန်အားဖြင့်၊ IIS သည် ဆာဗာများအားလုံးတန်းတူဖြစ်သော်လည်း မြင့်မားသောဝန်အောက်တွင် 8 cores ရှိသည့်လူတိုင်းထက် အနည်းငယ်ပိုမြန်ပါသည်။
၎င်းသည် တိုင်းတာမှုအမှားမဟုတ်ပါ၊ ဤအမှားသည် +-1ms ထက်မပိုပါ။ နှောင့်နှေးမှုများနှင့် RPR အတွက် တစ်စက္ကန့်လျှင် +- 2-3 တောင်းဆိုမှုထက် မပိုစေရ။
8 cores ပိုမိုဆိုးရွားသည့်ရလဒ်များသည် အံ့ဩစရာမဟုတ်ပါ၊ ကျွန်ုပ်တို့တွင် ပိုက်လိုင်းတစ်ခုလုံးကို အပြီးသတ်ရန် အချိန်ဘောင်တစ်ခုရှိလျှင် ကျွန်ုပ်တို့တွင် cores အများအပြားနှင့် SMT/Hyperthreading တို့သည် စွမ်းဆောင်ရည်ကို များစွာကျဆင်းစေသည်။
source: www.habr.com