ما در مورد روش شناسی صحبت کردیم در این مقاله ما HTTPS را آزمایش می کنیم، اما در سناریوهای واقعی تر. برای آزمایش، گواهی Let's Encrypt را به دست آوردیم و فشرده سازی Brotli را روی 11 فعال کردیم.
این بار ما سعی خواهیم کرد سناریوی استقرار یک سرور بر روی VDS یا به عنوان یک ماشین مجازی روی هاست با یک پردازنده استاندارد را بازتولید کنیم. برای این منظور محدودیتی در موارد زیر تعیین شد:
- 25% - که معادل فرکانس ~ 1350 مگاهرتز است
- 35٪ -1890 مگاهرتز
- 41٪ - 2214 مگاهرتز
- 65٪ - 3510 مگاهرتز
تعداد اتصالات یکباره از 500 به 1، 3، 5، 7 و 9 کاهش یافته است.
نتایج:
تاخیر:
TTFB به طور خاص به عنوان یک آزمایش جداگانه گنجانده شد، زیرا ابزار HTTPD یک کاربر جدید برای هر درخواست جداگانه ایجاد می کند. این تست هنوز کاملاً از واقعیت جدا است، زیرا کاربر همچنان روی چند صفحه کلیک می کند و در واقعیت TTFP نقش اصلی را بازی می کند.
اولین درخواست، معمولاً اولین درخواست پس از اولین راه اندازی ماشین مجازی IIS به طور متوسط 120 میلی ثانیه طول می کشد.
همه درخواست‌های بعدی TTFP 1.5 میلی‌ثانیه را نشان می‌دهند. Apache و Nginx در این زمینه عقب هستند. نویسنده شخصاً این آزمون را آشکارترین می داند و تنها بر اساس آن برنده را انتخاب می کند.
نتیجه تعجب آور نیست زیرا IIS محتوای ایستا فشرده شده را در حافظه پنهان ذخیره می کند و هر بار که به آن دسترسی پیدا می شود آن را فشرده نمی کند.
زمان صرف شده برای هر مشتری
برای ارزیابی عملکرد، یک آزمایش با 1 اتصال کافی است.
به عنوان مثال، IIS تست 5000 کاربر را در 40 ثانیه انجام داد که 123 درخواست در ثانیه است.
نمودارهای زیر زمان انتقال کامل محتوای سایت را نشان می دهد. این نسبت درخواست های تکمیل شده در یک زمان معین است. در مورد ما، 80 درصد از تمام درخواست‌ها در 8 میلی‌ثانیه در IIS و در 4.5 میلی‌ثانیه در Apache و Nginx پردازش شدند و 8 درصد از همه درخواست‌ها در Apache و Nginx در بازه زمانی حداکثر 98 میلی‌ثانیه تکمیل شدند.
زمانی که طی آن 5000 درخواست پردازش شد:
زمانی که طی آن 5000 درخواست پردازش شد:
اگر یک ماشین مجازی با CPU 3.5 گیگاهرتز و 8 هسته دارید، آنچه را که می خواهید انتخاب کنید. همه وب سرورها در این تست بسیار شبیه هستند. در زیر در مورد سرور وب برای هر میزبان صحبت خواهیم کرد.
وقتی صحبت از وضعیت کمی واقعی تر به میان می آید، همه وب سرورها مو به مو پیش می روند.
کارایی:
نمودار تاخیر در مقابل تعداد اتصالات همزمان. صاف و پایین تر بهتر است. 2٪ آخر از نمودارها حذف شدند زیرا آنها را ناخوانا می کردند.
حال بیایید گزینه ای را در نظر بگیریم که سرور در هاست مجازی میزبانی می شود. بیایید 4 هسته با فرکانس 2.2 گیگاهرتز و یک هسته با فرکانس 1.8 گیگاهرتز بگیریم.
نحوه مقیاس بندی
اگر تا به حال دیده اید که ویژگی های ولتاژ جریان تریودهای خلاء، پنتودها و غیره چگونه است، این نمودارها برای شما آشنا خواهند بود. این همان چیزی است که ما سعی می کنیم آن را بگیریم - اشباع. محدودیت زمانی است که مهم نیست چند هسته پرتاب کنید، افزایش عملکرد قابل توجه نخواهد بود.
پیش از این، کل چالش پردازش 98 درصد از درخواست‌ها با کمترین تأخیر برای همه درخواست‌ها بود و منحنی را تا حد ممکن صاف نگه داشت. حال با ساخت منحنی دیگر نقطه عملیاتی بهینه را برای هر یک از سرورها پیدا می کنیم.
برای انجام این کار، بیایید نشانگر Requests per second (RPR) را در نظر بگیریم. افقی فرکانس، عمودی تعداد درخواست های پردازش شده در ثانیه، خطوط تعداد هسته ها هستند.
همبستگی را نشان می دهد که Nginx چگونه درخواست ها را یکی پس از دیگری پردازش می کند. 8 هسته در این تست عملکرد بهتری دارند.
این نمودار به وضوح نشان می دهد که Nginx چقدر بهتر (نه خیلی) روی یک هسته واحد کار می کند. اگر Nginx دارید، اگر فقط هسته های ثابت را میزبانی می کنید، باید تعداد هسته ها را به یک کاهش دهید.
IIS، اگرچه طبق DevTools در کروم دارای کمترین TTFB است، اما در یک مبارزه جدی با تست استرس بنیاد آپاچی، موفق می‌شود هم به Nginx و هم Apache ببازد.
تمام انحنای نمودارها با روکش آهنی بازتولید می شود.
نوعی نتیجه گیری:
بله، آپاچی روی 1 و 8 هسته بدتر کار می کند، اما روی 4 کمی بهتر کار می کند.
بله، Nginx روی 8 هسته درخواست ها را یکی پس از دیگری بهتر پردازش می کند، روی 1 و 4 هسته، و زمانی که اتصالات زیادی وجود دارد بدتر کار می کند.
بله، IIS 4 هسته را برای بارهای کاری چند رشته ای و 8 هسته را برای بارهای کاری تک رشته ای ترجیح می دهد. در نهایت، IIS در 8 هسته تحت بار بالا کمی سریعتر از بقیه بود، اگرچه همه سرورها در یک سطح بودند.
این یک خطای اندازه گیری نیست، خطا در اینجا بیش از +-1 میلی ثانیه نیست. در تاخیر و بیش از +- 2-3 درخواست در ثانیه برای RPR.
نتایجی که در آن 8 هسته عملکرد بدتری دارند اصلاً تعجب آور نیستند، بسیاری از هسته‌ها و SMT/Hyperthreading عملکرد را تا حد زیادی کاهش می‌دهند اگر یک چارچوب زمانی داشته باشیم که در آن باید کل خط لوله را تکمیل کنیم.
منبع: www.habr.com