شاید بتوان گفت در این مقاله دست خود را در مهندسی معکوس امتحان خواهیم کرد. ما دست‌های کثیف‌مان را زیر سر هر وب سرور قرار می‌دهیم و از آنها به گونه‌ای سوءاستفاده می‌کنیم که هیچ‌کس از آن سوء استفاده نمی‌کند.
این آزمایش اندازه گیری یک اسب کروی در خلاء است، چیزی بیش از داده هایی که به دست آمده است و اکنون نمی دانیم با آن چه کنیم.
روش شناسی
سیستم عامل Nginx و Apache Ubuntu 18.04 LTS، برای IIS Windows Server Core 2019 است. قبل از انجام آزمایشات، همه سیستم عامل ها آخرین به روز رسانی ها را از تاریخ 04.12.2019 دسامبر XNUMX دریافت کردند.
آزمایشات منحصراً از طریق HTTP انجام شد. هر وب سرور همان صفحه را اجرا می کرد، یک قالب رایگان جکیل از Codrops. . هر وب سرور فشرده سازی gzip غیرفعال بود.
تست توان عملیاتی با ابزارهای Httpd با آرگومان های زیر انجام شد:
ab -n 50000 -c 500 http://192.168.76.204:80/سرورها به 10، 5 و 1 درصد هسته روی 8، 4 و یک هسته محدود شده بودند. میز تست یک کامپیوتر با 9900K@5400MHz بود، به این معنی که سروری که محدودیت 10٪ دریافت می کند، حدود 540 مگاهرتز در هر هسته دریافت می کند.
تست TTFB زمانی انجام شد که سرور ابتدا بوت شد و با استفاده از DevTools اندازه‌گیری شد؛ پس از دریافت نتیجه، سرور خاموش شد و به نقطه بازرسی قبلی برگشت تا ظاهر هر نوع حافظه پنهان از بین برود.
تستر و وب سرور روی یک میزبان و روی یک سوئیچ مجازی قرار داشتند.
برای ارزیابی فوری زیرسیستم دیسک، نتایج معیارهای ATTO و CrystalDIskMark به منظور داشتن ایده ای از تنگناها.
داده های گرفته شده از ماشین مجازی:
نتایج:
TTFB:
میانگین TTFB برای IIS کوچکترین است، 0,5ms، در مقابل 1,4ms برای Apache و 4ms برای Nginx.
کارایی:
ابتدا، بیایید ببینیم که هر سرور بر اساس تعداد هسته‌ها چقدر مقیاس می‌شود.
نمودار تعداد تماس‌های تستر با سرور وب و تأخیر را نشان می‌دهد. نمودار نشان می دهد که NGINX 98٪ از تمام درخواست ها را پردازش کرده و سایت را در 20 میلی ثانیه یا کمتر تحویل می دهد. IIS مانند آپاچی 5 درصد آخرین تماس ها را به ترتیب در 76 و 14 میلی ثانیه انجام داد.
این نمودار میانگین زمان پردازش یک درخواست را در طول تست استرس نشان می دهد.
همانطور که از نمودارها می بینید، IIS هر دو Apache و Nginx را منفجر کرد و تحت بارگذاری بالا به میزان قابل توجهی کاهش یافت.
IIS به وضوح 4 هسته را به XNUMX ترجیح می دهد، تاخیر کمتری را در XNUMX نشان می دهد، اما به شدت طرفدار یک هسته نیست.
NGINX در تمام 8 هسته به خوبی مقیاس می شود و برای آپاچی، سناریوی تک هسته ای بهترین انتخاب به نظر می رسد.
مقیاس پذیری:
nginx:
حال اجازه دهید مقیاس پذیری را از نظر فرکانس و تعداد هسته ها بررسی کنیم.
Nginx تست هایی را با محدودیت 1% برای 4 و 1 هسته قبول نکرد؛ زمانی که از 2000 درخواست فراتر رفت، ارتباط با تستر را قطع کرد.
آپاچی:
آپاچی مانند Nginx با پردازش 2500 درخواست، منصرف شد و اتصال را مسدود کرد. آپاچی در تست 8، 4 و 1 هسته ای با محدودیت 1% مردود شد، اما علاوه بر این تست را با محدودیت 5% روی یک هسته که بدتر از Nginx است، مردود شد.
IIS:
در طول آزمایشات، IIS صف عظیمی از درخواست ها را جمع آوری کرد اما هر یک از آنها را پردازش کرد. ظاهراً هیچ مهلتی برای پردازش درخواست تنظیم نشده است.
نمودار زمان انجام تست را نشان می دهد. تنظیمات آزمایشی کاملاً پوچ کنار گذاشته شد. این نمودار نشان می دهد که IIS در مورد سخت افزار چقدر سخت افزاری است و NGINX چقدر فوق العاده است.
مقیاس پذیری از دیسک:
nginx:
حال اجازه دهید مقیاس پذیری را از نظر فرکانس و تعداد هسته ها و سرعت دیسک بررسی کنیم.
این بار Nginx در 4 تست به جای دو تست شکست خورد.
آپاچی:
آپاچی با همان تعداد تست قبلی شکست خورد.
IIS:
IIS یک نمودار تقریباً یکسان را نشان می دهد، گویی هیچ محدودیتی برای دیسک وجود ندارد. به طور کلی گرافیک همه سرورها تغییر چندانی نداشت یعنی هر کدام از آنها اطلاعات استاتیک را در رم کش می کردند و از آنجا سرویس می دادند. در اینجا ما گلوگاه اصلی را می بینیم - خود وب سرور.
برای نتیجه‌گیری بر اساس این آزمایش خیلی زود است؛ ما هنوز HTTPS، فشرده‌سازی و HTTP/2 را با گواهی زنده از Let's Encrypt آزمایش نکرده‌ایم. در مقاله بعدی در این مورد صحبت خواهیم کرد.
منبع: www.habr.com