پدې مقاله کې به موږ د ریورس انجینرۍ په برخه کې خپل لاس هڅه وکړو ، یو څوک شاید ووایی. موږ به خپل ناپاک لاسونه د هر ویب سرور تر پوښ لاندې راوړو، په داسې طریقو به یې استحصال کړو چې هیڅوک به یې استحصال نه کړي.
دا ازموینه په خلا کې د کروي آس اندازه کول دي، پرته له دې چې ترلاسه شوي معلومات، او اوس موږ نه پوهیږو چې د هغې سره څه وکړي.
میتودولوژي
د Nginx او Apache لپاره عملیاتي سیسټم د Ubuntu 18.04 LTS دی، د IIS وینډوز سرور کور 2019 لپاره. د ازموینې دمخه، ټولو عملیاتي سیسټمونو د دسمبر 04.12.2019، XNUMX پورې وروستي تازه معلومات ترلاسه کړل.
ازموینې په ځانګړي ډول په HTTP کې ترسره شوې. هر ویب سرور ورته پاڼه چلوله، د کوډروپس څخه وړیا جیکیل ټیمپلیټ. . هر ویب سرور د gzip کمپریشن غیر فعال کړی و.
د Throput ازموینه د Httpd-tools سره د دلیلونو سره ترسره شوه:
ab -n 50000 -c 500 http://192.168.76.204:80/سرورونه په 10، 5، او یو کور کې د 1، 8، او 4 سلنې کور پورې محدود وو. د ازموینې بینچ د 9900K@5400MHz سره یو کمپیوټر و ، پدې معنی چې سرور چې د 10٪ حد ترلاسه کوي په هر کور کې شاوخوا 540MHz ترلاسه کوي.
د TTFB ازموینه هغه وخت ترسره شوه کله چې سرور لومړی بوټ شو او د DevTools په کارولو سره اندازه شو؛ د پایلې ترلاسه کولو وروسته ، سرور بند شو او پخوانۍ پوستې ته وګرځول شو ترڅو د هر ډول کیچ ظهور له مینځه ویسي.
ټیسټر او ویب سرور په ورته کوربه او ورته مجازی سویچ کې وو.
د ډیسک فرعي سیسټم سمدستي ارزولو لپاره، د ATTO او CrystalDIskMark بنچمارک پایلې د دې لپاره چې د خنډونو په اړه نظر ولرئ.
د مجازی ماشین څخه اخیستل شوي معلومات:
پایلې:
TTFB:
د IIS لپاره اوسط TTFB ترټولو کوچنی دی، 0,5ms، د اپاچي لپاره 1,4ms او د Nginx لپاره 4ms.
له لارې:
لومړی، راځئ چې وګورو چې هر سرور د کور شمیرې پراساس څومره ښه اندازه کوي.
ګراف ویب سرور ته د ټیسټر تلیفونونو شمیر او ځنډ ښیې. ګراف ښیې چې NGINX د ټولو غوښتنو 98٪ پروسس کړی، سایټ په 20ms یا لږ کې وړاندې کوي. IIS، د اپاچي په څیر، په ترتیب سره په 5ms او 76ms کې د ټولو تلیفونونو وروستي 14٪ بشپړ کړي.
ګراف د فشار ازموینې په جریان کې د یوې غوښتنې لپاره اوسط پروسس وخت ښیې.
لکه څنګه چې تاسو د ګرافونو څخه لیدلی شئ، IIS دواړه اپاچي او نګینکس له مینځه یوسي، د لوړ بار لاندې د پام وړ ورو ورو.
IIS په واضح ډول د 4 په پرتله XNUMX کورونه غوره کړل، په XNUMX کې ټیټ ځنډ ښیي، مګر په کلکه یې د یوې کور پلوي نه ده کړې.
NGINX په ټولو 8 کورونو کې ښه اندازه کوي، او د اپاچي لپاره، د واحد کور سناریو غوره انتخاب ښکاري.
د توزیع وړتیا:
نګینیکس:
اوس راځئ چې د فریکونسۍ او د کور شمیرې له مخې توزیع کولو ته وګورو.
نګینکس د 1 او 4 کور لپاره د 1٪ محدودیت سره ازموینې ندي تیرې کړې؛ کله چې دا د 2000 غوښتنو څخه ډیر شو ، نو دا د ټیسټر سره اړیکه ختمه کړه.
اپاچی
اپاچي، لکه د نګینکس، د 2500 غوښتنې پروسس کولو سره، پیوستون یې پریښود او بند یې کړ. اپاچی په 8، 4 او 1 کورونو کې د 1٪ محدودیت سره ازموینه ناکامه کړه، مګر سربیره پردې دا په یوه کور کې د 5٪ محدودیت سره ازموینه هم ناکامه کړه، کوم چې د Nginx څخه بد دی.
IIS:
د ازموینو په جریان کې، IIS د غوښتنو لوی قطار راټول کړ مګر هر یو یې پروسس کړ. په ښکاره ډول، د بکس څخه بهر د غوښتنې پروسس کولو لپاره هیڅ مهال ویش شتون نلري.
چارټ هغه وخت ښیې چې د ازموینې بشپړولو لپاره یې اخیستی. په بشپړ ډول بې ځایه ازموینې ترتیبونه رد شوي. ډیاګرام ښیې چې IIS څومره غوښتنه کوي کله چې دا هارډویر ته راځي ، او NGINX څومره عالي دی.
د ډیسک څخه توزیع کول:
نګینیکس:
اوس راځئ چې د فریکونسۍ او د کورونو شمیر او ډیسک سرعت له مخې پیمانه وګورو.
دا ځل نګینکس د دوه پرځای 4 ازموینې ناکامه شوې.
اپاچی
اپاچی د تیر ځل په څیر ورته شمیر ازموینو کې ناکام شو.
IIS:
IIS تقریبا ورته ګراف ښیې، لکه څنګه چې د ډیسک محدودیتونه شتون نلري. په عموم کې، د ټولو سرورونو ګرافیک ډیر بدلون نه دی کړی، دا پدې مانا ده چې هر یو یې په RAM کې جامد ډاټا ذخیره کړې او له هغه ځایه یې خدمت کړی. دلته موږ اصلي خنډ ګورو - پخپله ویب سرور.
د دې ازموینې پراساس نتیجې ته رسیدل ډیر وختي دي؛ موږ لا تر اوسه د لیټس انکریپټ څخه د ژوندي سند سره HTTPS، کمپریشن او HTTP/2 ازموینه نه ده کړې. موږ به په راتلونکې مقاله کې پدې اړه خبرې وکړو.
سرچینه: www.habr.com