موږ د میتودولوژي په اړه خبرې وکړې
دا ځل به موږ هڅه وکړو چې په VDS کې د سرور ځای په ځای کولو سناریو بیا تولید کړو یا د معیاري پروسیسر سره په کوربه کې د مجازی ماشین په توګه. د دې هدف لپاره، یو حد ټاکل شوی و:
- 25٪ - کوم چې د ~ 1350 MHz فریکونسۍ سره برابر دی
- 35% -1890MHz
- 41٪ - 2214 MHz
- 65٪ - 3510 MHz
د یو وخت اړیکو شمیر له 500 څخه 1، 3، 5، 7 او 9 ته راټیټ شوی،
پایلې:
ځنډونه:
TTFB په ځانګړې توګه د جلا ازموینې په توګه شامل شوی و، ځکه چې د HTTPD وسیلې د هرې انفرادي غوښتنې لپاره نوی کاروونکي جوړوي. دا ازموینه لاهم د واقعیت څخه خورا جلا ده، ځکه چې کاروونکي به لاهم یو څو پاڼې کلیک وکړي، او په حقیقت کې TTFP به اصلي رول ولوبوي.
لومړی، عموما د IIS مجازی ماشین د لومړي پیل وروسته لومړنۍ غوښتنه په اوسط ډول 120 ms اخلي.
ټولې ورپسې غوښتنې د 1.5 ms TTFP ښیي. اپاچي او نګینکس پدې برخه کې وروسته پاتې دي. په شخصي توګه، لیکوال دا ازموینه خورا ښکاره ګڼي او یوازې د هغې پر بنسټ ګټونکي غوره کوي.
پایله د حیرانتیا خبره نده ځکه چې د IIS کیچ دمخه جامد مینځپانګه کمپریس کړې او هرکله چې لاسرسی ورته کیږي دا نه فشاروي.
د هر پیرودونکي مصرف وخت
د فعالیت ارزولو لپاره، د 1 واحد ارتباط سره ازموینه کافي ده.
د مثال په توګه، IIS په 5000 ثانیو کې د 40 کاروونکو ازموینه بشپړه کړه، چې په هره ثانیه کې 123 غوښتنې دي.
لاندې ګرافونه هغه وخت ښیې چې د سایټ مینځپانګه په بشپړ ډول لیږدول کیږي. دا د هغو غوښتنو تناسب دی چې په ټاکل شوي وخت کې بشپړ شوي. زموږ په قضیه کې، د ټولو غوښتنو 80٪ په IIS کې په 8ms کې او په Apache او Nginx کې په 4.5ms کې پروسس شوي، او په اپاچي او نګینکس کې د ټولو غوښتنو 8٪ تر 98 ملی ثانیو پورې وقفه کې بشپړ شوي.
په هغه وخت کې چې 5000 غوښتنې پروسس شوي:
په هغه وخت کې چې 5000 غوښتنې پروسس شوي:
که تاسو د 3.5GHz CPU او 8 کور سره مجازی ماشین لرئ، نو هغه څه غوره کړئ چې تاسو یې غواړئ. ټول ویب سرورونه پدې ازموینه کې خورا ورته دي. موږ به د لاندې هر کوربه لپاره د کوم ویب سرور غوره کولو په اړه وغږیږو.
کله چې دا یو څه ډیر حقیقي وضعیت ته راځي، ټول ویب سرورونه سر ته ځي.
له لارې:
د ځنډونو ګراف د یو وخت اړیکو شمیر په پرتله. نرم او ښکته غوره دی. وروستي 2٪ له چارټونو څخه لرې شوي ځکه چې دوی به دوی د لوستلو وړ نه کړي.
اوس راځئ هغه اختیار په پام کې ونیسو چیرې چې سرور په مجازی کوربه توب کې کوربه شوی. راځئ چې 4 کورونه په 2.2 GHz او یو کور په 1.8 GHz کې واخلو.
څنګه اندازه کول
که تاسو کله هم لیدلي وي چې د ویکیوم ټرایډونو، پینټوډونو او داسې نورو اوسني ولتاژ ځانګړتیاوې څه ډول ښکاري، دا ګرافونه به تاسو ته پیژندل شوي وي. دا هغه څه دي چې موږ یې د نیولو هڅه کوو - سنتریت. حد هغه دی کله چې مهمه نده چې تاسو څومره کورونه وغورځوئ ، د فعالیت زیاتوالی به د پام وړ نه وي.
پخوا، ټوله ننګونه د ټولو غوښتنو لپاره د ټیټ ځنډ سره د 98٪ غوښتنې پروسس کول وو، د امکان تر حده فلیټ ساتل. اوس، د بل وکر په جوړولو سره، موږ به د هر سرور لپاره غوره عملیاتي نقطه پیدا کړو.
د دې کولو لپاره، راځئ چې د هرې ثانیې غوښتنې (RPR) شاخص واخلو. افقی فریکونسۍ ده، عمودی د غوښتنې شمیره ده چې په هره ثانیه کې پروسس کیږي، کرښې د کور شمیره ده.
اړیکه ښیې چې څومره ښه Nginx پروسې یو له بل وروسته غوښتنه کوي. 8 کورونه پدې ازموینه کې ښه فعالیت کوي.
دا ګراف په روښانه ډول ښیې چې څومره ښه (ډیر نه) Nginx په یو واحد کور کې کار کوي. که تاسو نګینکس لرئ، تاسو باید د کور شمیر یو ته کم کړئ که تاسو یوازې جامد کوربه یاست.
IIS، که څه هم دا په کروم کې د DevTools په وینا ترټولو ټیټ TTFB لري، د اپاچي فاؤنڈیشن څخه د فشار ازموینې سره په جدي مبارزه کې دواړه نګینکس او اپاچي ته له لاسه ورکولو اداره کوي.
د ګرافونو ټول منحلات د اوسپنې پوښل شوي بیا تولید شوي.
یو ډول پایله:
هو، اپاچي په 1 او 8 کور کې بد کار کوي، مګر په 4 کې یو څه ښه کار کوي.
هو، په 8 کور پروسو کې نګینکس په 1 او 4 کورونو کې یو له بل وروسته ښه غوښتنه کوي، او خراب کار کوي کله چې ډیری اړیکې شتون ولري.
هو، IIS د څو تریډ شوي کاري بارونو لپاره 4 کورونه غوره کوي او د واحد تار شوي کاري بارونو لپاره 8 کورونه غوره کوي. په نهایت کې ، IIS د لوړ بار لاندې 8 کورونو کې د هرچا په پرتله یو څه ګړندی و ، که څه هم ټول سرورونه په مساوي وو.
دا د اندازه کولو تېروتنه نه ده، دلته تېروتنه له +-1ms څخه زیاته نه ده. په ځنډ کې او د RPR لپاره په هره ثانیه کې له +- 2-3 څخه ډیر غوښتنې.
هغه پایلې چیرې چې د 8 کورونه خراب ترسره کوي هیڅ حیرانتیا نلري، ډیری کورونه او SMT/Hyperthreading فعالیت خورا خرابوي که چیرې موږ د وخت چوکاټ ولرو په کوم کې چې موږ باید ټول پایپ لاین بشپړ کړو.
سرچینه: www.habr.com