WEB ဆာဗာများ၏တိုက်ပွဲ။ အပိုင်း 1 – HTTP သည် အဆက်အသွယ်ပြတ်တောက်နေသည်-

ဒီဆောင်းပါးမှာ Reverse Engineering မှာ ကျွန်တော်တို့ရဲ့ လက်ကို စမ်းကြည့်မယ် ထင်ပါတယ်။ ဝဘ်ဆာဗာတစ်ခုစီ၏ အဖုံးအောက်တွင် ကျွန်ုပ်တို့၏ညစ်ပတ်သောလက်များကို မည်သူမျှ အမြတ်ထုတ်မည်မဟုတ်သော နည်းလမ်းများဖြင့် ၎င်းတို့ကို အသုံးချသွားမည်ဖြစ်သည်။

ဤစမ်းသပ်မှုသည် လေဟာနယ်တစ်ခုအတွင်း လုံးပတ်မြင်းတစ်ကောင်၏ တိုင်းတာမှုဖြစ်ပြီး ရရှိခဲ့သည့် ဒေတာထက် ဘာမှမပိုပါ၊ ယခု ကျွန်ုပ်တို့ ၎င်းနှင့် မည်သို့လုပ်ဆောင်ရမည်ကို မသိနိုင်ပါ။

စက်မှုပညာ

Nginx နှင့် Apache အတွက် လည်ပတ်မှုစနစ်သည် Ubuntu 18.04 LTS ဖြစ်ပြီး IIS Windows Server Core 2019 အတွက် Ubuntu ဖြစ်သည်။ စမ်းသပ်မှုများမပြုလုပ်မီ၊ လည်ပတ်မှုစနစ်အားလုံးသည် ဒီဇင်ဘာ 04.12.2019 ရက်၊ XNUMX ခုနှစ်အထိ နောက်ဆုံးအပ်ဒိတ်များကို ရရှိခဲ့သည်။

စမ်းသပ်မှုများကို HTTP ဖြင့် သီးသန့်ပြုလုပ်ခဲ့သည်။ ဝဘ်ဆာဗာတစ်ခုစီသည် Codrops မှ အခမဲ့ Jekyll နမူနာပုံစံကို တူညီသော စာမျက်နှာတစ်ခုအဖြစ် လုပ်ဆောင်သည်။ link ကို. ဝဘ်ဆာဗာတစ်ခုစီတွင် gzip ချုံ့ခြင်းကို ပိတ်ထားသည်။

အကြောင်းပြချက်များဖြင့် တစ်ဆင့်ခံစမ်းသပ်မှုကို Httpd-tools ဖြင့် လုပ်ဆောင်ခဲ့သည်-

ab -n 50000 -c 500 http://192.168.76.204:80/

ဆာဗာများကို 10၊ 5 နှင့် core တစ်ခုတွင် core 1၊ 8 နှင့် 4 ရာခိုင်နှုန်းအထိ ကန့်သတ်ထားသည်။ စမ်းသပ်ခုံတန်းသည် 9900K@5400MHz ရှိသော ကွန်ပျူတာဖြစ်ပြီး ဆိုလိုသည်မှာ 10% ကန့်သတ်ချက်ကို လက်ခံရရှိသည့် ဆာဗာသည် core တစ်ခုလျှင် 540MHz ခန့် ရရှိသည်။

DevTools ကို အသုံးပြု၍ ဆာဗာကို ပထမဆုံး စတင်ဖွင့်ပြီး တိုင်းတာသည့်အခါ TTFB စမ်းသပ်မှုကို လုပ်ဆောင်ခဲ့သည်၊ ရလဒ်ကို ရရှိပြီးနောက်၊ ဆာဗာကို ပိတ်ပြီး မည်သည့် ကက်ရှ်များ၏ အသွင်အပြင်ကိုမဆို ဖယ်ရှားရန်အတွက် ယခင်စစ်ဆေးရေးဂိတ်သို့ ပြန်လှည့်သွားပါသည်။

စမ်းသပ်သူနှင့် ဝဘ်ဆာဗာသည် တူညီသော host နှင့် တူညီသော virtual switch တွင် ရှိနေပါသည်။

disk subsystem ကိုချက်ချင်းအကဲဖြတ်ရန်၊ ATTO နှင့် CrystalDIskMark စံနှုန်းများ၏ရလဒ်များသည် ပိတ်ဆို့မှုများကို စိတ်ကူးတစ်ခုရစေရန်။

virtual machine မှရယူသောဒေတာ

ရလဒ်များ -

TTFB-

IIS အတွက် ပျမ်းမျှ TTFB သည် အသေးငယ်ဆုံး၊ 0,5ms၊ Apache အတွက် 1,4ms နှင့် Nginx အတွက် 4ms ဖြစ်သည်။

throughput:

ဦးစွာ၊ cores အရေအတွက်အပေါ်အခြေခံ၍ server တစ်ခုချင်းစီ၏အတိုင်းအတာမည်မျှကောင်းမွန်သည်ကိုကြည့်ကြပါစို့။

ဂရပ်သည် ဝဘ်ဆာဗာသို့ စမ်းသပ်သူခေါ်ဆိုမှုအရေအတွက်နှင့် latency ကိုပြသသည်။ NGINX သည် တောင်းဆိုချက်အားလုံး၏ 98% ကို လုပ်ဆောင်ပြီး 20ms သို့မဟုတ် ထိုထက်နည်းသော ဆိုက်ကို ပေးပို့ကြောင်း ဂရပ်က ဖော်ပြသည်။ Apache ကဲ့သို့ IIS သည် 5ms နှင့် 76ms တွင် ခေါ်ဆိုမှုအားလုံး၏ နောက်ဆုံး 14% ကို ပြီးမြောက်ခဲ့သည်။

ဂရပ်သည် စိတ်ဖိစီးမှုစမ်းသပ်မှုတစ်ခုအတွင်း တောင်းဆိုချက်တစ်ခုအတွက် ပျမ်းမျှလုပ်ဆောင်ချိန်ကို ပြသသည်။

ဂရပ်များတွင် သင်တွေ့မြင်ရသည့်အတိုင်း၊ IIS သည် Apache နှင့် Nginx နှစ်ခုလုံးကို စွန့်ထုတ်လိုက်ပြီး မြင့်မားသောဝန်အောက်တွင် သိသိသာသာနှေးကွေးသွားသည်။ 

IIS သည် 4 ထက် XNUMX cores များကို ရှင်းရှင်းလင်းလင်း ဦးစားပေးထားပြီး XNUMX တွင် latency နည်းပါးသည်ကို ပြသသော်လည်း core တစ်ခုအား ပြင်းပြင်းထန်ထန် မကြိုက်ပါ။

NGINX သည် core 8 ခုလုံးတွင် ကောင်းမွန်စွာ တိုင်းတာနိုင်ပြီး Apache အတွက် single-core scenario သည် အကောင်းဆုံးရွေးချယ်မှုဖြစ်ပုံရသည်။

အတိုင်းအတာ-

ငငင်:

ယခု ကြိမ်နှုန်းနှင့် cores အရေအတွက်အရ scalability ကို ကြည့်ကြပါစို့။ 

Nginx သည် 1 နှင့် 4 cores အတွက် 1% ကန့်သတ်ချက်ဖြင့် စစ်ဆေးမှုများကို မအောင်မြင်ခဲ့ဘဲ တောင်းဆိုမှု 2000 ကိုကျော်လွန်သောအခါ၊ ၎င်းသည် စမ်းသပ်သူနှင့် ချိတ်ဆက်မှုကို ရပ်ဆိုင်းခဲ့သည်။

Apache ကို:

Nginx ကဲ့သို့ Apache သည် တောင်းဆိုချက် 2500 ကို လုပ်ဆောင်ပြီး ချိတ်ဆက်မှုကို စွန့်လွှတ်ပြီး ပိတ်လိုက်သည်။ Apache သည် 8၊ 4 နှင့် 1 cores များတွင် 1% ကန့်သတ်ချက်ဖြင့် စမ်းသပ်မှုကို ကျရှုံးခဲ့သော်လည်း Nginx ထက် ပိုဆိုးသည့် core တစ်ခုတွင် 5% ကန့်သတ်ချက်ဖြင့် စမ်းသပ်မှုကို ကျရှုံးခဲ့သည်။

IIS-

စမ်းသပ်မှုများအတွင်း IIS သည် အလွန်ကြီးမားသော တောင်းဆိုမှုများကို စုဆောင်းခဲ့သော်လည်း ၎င်းတို့တစ်ခုစီကို လုပ်ဆောင်ခဲ့သည်။ ထင်ရှားသည်မှာ၊ ဘောက်စ်အတွင်းမှ တောင်းဆိုမှုလုပ်ဆောင်ရန်အတွက် အချိန်ကုန်သတ်မှတ်ထားခြင်းမရှိပါ။

ဇယားသည် စာမေးပွဲပြီးအောင်ပြုလုပ်ရန် အချိန်ကိုပြသသည်။ လုံးဝ အဓိပ္ပါယ်မဲ့သော စမ်းသပ်မှုပုံစံများကို ဖျက်သိမ်းလိုက်ပါသည်။ ပုံကြမ်းသည် ဟာ့ဒ်ဝဲနှင့်ပတ်သက်လာသောအခါ IIS မည်မျှတောင်းဆိုနေပုံနှင့် NGINX သည် မည်မျှအံ့သြဖွယ်ကောင်းသည်ကို ပြသသည်။

ဒစ်ခ်မှ ချဲ့ထွင်နိုင်မှု-

ငငင်:

ယခု ကြိမ်နှုန်းနှင့် cores အရေအတွက်နှင့် disk speed အရ scalability ကို ကြည့်ကြပါစို့။ 

ဤတစ်ကြိမ်တွင် Nginx သည် နှစ်ခုအစား စမ်းသပ်မှု 4 ခု ကျရှုံးခဲ့သည်။

Apache ကို:

Apache သည် ယခင်အကြိမ်ကဲ့သို့ စမ်းသပ်မှုအရေအတွက်အတိုင်း ကျရှုံးခဲ့သည်။

IIS-

IIS သည် ဒစ်ခ်ကန့်သတ်ချက်များမရှိသကဲ့သို့ အလားတူနီးပါးတူညီသောဂရပ်ကိုပြသသည်။ ယေဘူယျအားဖြင့်၊ ဆာဗာအားလုံး၏ ဂရပ်ဖစ်များသည် များစွာမပြောင်းလဲဘဲ၊ ဆိုလိုသည်မှာ ၎င်းတို့တစ်ခုစီသည် RAM တွင် static data များကို သိမ်းဆည်းထားပြီး ထိုနေရာမှ လုပ်ဆောင်ပေးခြင်းဖြစ်သည်။ ဤနေရာတွင် ကျွန်ုပ်တို့သည် အဓိက ပိတ်ဆို့မှုကို မြင်နေရသည် - ဝဘ်ဆာဗာ ကိုယ်တိုင်။

ဤစမ်းသပ်မှုအပေါ်အခြေခံ၍ ကောက်ချက်ဆွဲရန်စောလွန်းပါသည်၊ ကျွန်ုပ်တို့သည် HTTPS၊ ချုံ့မှုနှင့် HTTP/2 ကို Let's Encrypt မှ တိုက်ရိုက်အသိအမှတ်ပြုလက်မှတ်ဖြင့် မစမ်းသပ်ရသေးပါ။ ဒီအကြောင်းကို နောက်ဆောင်းပါးမှာ ပြောပါမယ်။

source: www.habr.com