هن آرٽيڪل ۾ اسان ريورس انجنيئرنگ تي اسان جي هٿ جي ڪوشش ڪنداسين، هڪ چئي سگهي ٿو. اسان پنهنجا گندا هٿ هر ويب سرور جي هود هيٺ آڻينداسين، انهن کي اهڙي طريقي سان استحصال ڪنداسين ته ڪو به استحصال نه ڪندو.
هي امتحان هڪ خلا ۾ گول گھوڙي جي ماپ آهي، ڊيٽا کان وڌيڪ ڪجھ به نه آهي جيڪو حاصل ڪيو ويو، ۽ هاڻي اسان کي خبر ناهي ته ان سان ڇا ڪجي.
طريقو
Nginx ۽ Apache لاءِ آپريٽنگ سسٽم آهي Ubuntu 18.04 LTS، IIS Windows Server Core 2019 لاءِ. ٽيسٽن کان اڳ، سڀني آپريٽنگ سسٽمن کي 04.12.2019 ڊسمبر XNUMX تائين تازيون تازه ڪاريون مليون.
ٽيسٽ خاص طور تي HTTP تي ڪيا ويا. هر ويب سرور ساڳيو صفحو هلائي ٿو، هڪ مفت Jekyll ٽيمپليٽ Codrops کان. . هر ويب سرور کي 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 Apache لاء ۽ 4ms Nginx لاء.
عمل:
پهرين، اچو ته ڏسو ته هر سرور ڪور جي تعداد جي بنياد تي ڪيترو چڱي ريت ماپ ڪري ٿو.
گراف ڏيکاري ٿو ٽيسٽر ڪالن جو تعداد ويب سرور تي ۽ ويڪرائي. گراف ڏيکاري ٿو ته NGINX سڀني درخواستن جو 98٪ پروسيس ڪيو، 20ms يا گهٽ ۾ سائيٽ پهچائڻ. IIS، Apache وانگر، مڪمل ڪيو آخري 5٪ سڀني ڪالن جو 76ms ۽ 14ms ۾، ترتيب سان.
گراف ڏيکاري ٿو اوسط پروسيسنگ وقت هڪ درخواست لاء هڪ دٻاء جي امتحان دوران.
جئين توهان گرافس مان ڏسي سگهو ٿا، IIS ٻنهي اپاچي ۽ نينڪسڪس کي ڌڪي ڇڏيو، تمام گهڻي لوڊ هيٺ سست ٿي.
IIS واضح طور تي 4 ڪور کي XNUMX کان وڌيڪ ترجيح ڏني، XNUMX تي گھٽ دير ڏيکاريندي، پر ھڪڙي ڪور کي مضبوط طور تي پسند نه ڪيو.
NGINX تمام 8 ڪور تي چڱي طرح ماپ ڪري ٿو، ۽ اپاچي لاء، سنگل-ڪور منظر لڳي ٿو بهترين انتخاب.
پيماني جي صلاحيت:
نگنڪس:
هاڻي اچو ته تعدد ۽ ڪور جي تعداد جي لحاظ کان اسڪاليبلٽي کي ڏسو.
نينگڪس 1 ۽ 4 ڪور لاءِ 1٪ جي حد سان ٽيسٽ پاس نه ڪيو؛ جڏهن اهو 2000 درخواستن کان وڌي ويو، اهو ٽيسٽر سان رابطو ختم ڪيو.
Apache:
Apache، Nginx وانگر، 2500 درخواستن تي عمل ڪندي، ڪنيڪشن کي ڇڏي ڏنو ۽ بند ڪيو. Apache 8، 4 ۽ 1 ڪور تي ٽيسٽ ۾ ناڪام ٿيو 1٪ جي حد سان، پر ان کان علاوه اهو پڻ ناڪام ٿيو ٽيسٽ کي هڪ ڪور تي 5٪ جي حد سان، جيڪو Nginx کان وڌيڪ خراب آهي.
آئي ايس:
تجربن دوران، IIS درخواستن جي هڪ وڏي قطار گڏ ڪئي پر انهن مان هر هڪ تي عمل ڪيو. ظاهري طور تي، دٻي مان ٻاهر نه آهن درخواست جي پروسيسنگ لاءِ وقت مقرر ٿيل آهن.
چارٽ ڏيکاري ٿو ته اهو امتحان مڪمل ڪرڻ لاء وقت ورتو. مڪمل طور تي غير معمولي جاچ واري ترتيب کي رد ڪيو ويو. آريگرام ڏيکاري ٿو ته IIS ڪيترو گهربل آهي جڏهن اهو هارڊويئر تي اچي ٿو، ۽ ڪيترو شاندار NGINX آهي.
ڊسڪ مان اسڪيلبلٽي:
نگنڪس:
ھاڻي اچو ته تعدد جي لحاظ کان اسڪاليبلٽي کي ڏسو ۽ ڪور جي تعداد ۽ ڊسڪ جي رفتار.
هن ڀيري نينگڪس ٻن بدران 4 ٽيسٽ ناڪام ٿيا.
Apache:
Apache ناڪام ٿي ويو ٽيسٽ جو ساڳيو تعداد آخري وقت وانگر.
آئي ايس:
IIS هڪ لڳ ڀڳ هڪجهڙائي گراف ڏيکاري ٿو، ڄڻ ته ڊسڪ پابنديون نه هيون. عام طور تي، سڀني سرورن جي گرافڪس گهڻو تبديل نه ڪيو، جنهن جو مطلب آهي ته انهن مان هر هڪ جامد ڊيٽا کي رام ۾ محفوظ ڪيو ۽ ان کي اتان کان خدمت ڪيو. هتي اسان ڏسون ٿا مکيه رڪاوٽ - ويب سرور پاڻ.
هن جاچ جي بنياد تي نتيجو ڪڍڻ تمام جلدي آهي؛ اسان اڃا تائين ٽيسٽ نه ڪيو آهي HTTPS، ڪمپريشن ۽ HTTP/2 کي هڪ لائيو سرٽيفڪيٽ سان گڏ Let's Encrypt. اسان ان بابت ايندڙ مضمون ۾ ڳالهائينداسين.
جو ذريعو: www.habr.com