Про методику ми розповідали в статті, у цій ми тестуємо HTTPS, але у більш реалістичних сценаріях. Для тестування було отримано сертифікат Let's Encrypt, увімкнено стиснення Brotli на 11.
На цей раз спробуємо відтворити сценарій розгортання сервера на VDS або як віртуальну машину на хості з типовим процесором. Для цього встановлювали ліміт:
- 25% - Що в перерахунку на частоту ~ 1350МГц
- 35%-1890Мгц
- 41% - 2214Мгц
- 65% - 3510Мгц
Кількість одноразових підключень скоротилася з 500 до 1, 3, 5, 7 та 9,
Результати:
Затримки:
TTFB спеціально був винесений як окремий тест, тому що HTTPD Tools для кожного окремого запиту створює як нового користувача. Цей тест все ще досить відірваний від реальності, тому що пару сторінок користувач все одно натисне, і в реальності головну роль зіграє TTFP.
Перший, взагалі, перший запит після першого старту віртуальної машини IIS відпрацьовує в середньому за 120 мс.
Всі наступні запити показують TTFP 1.5 мс. Apache та Nginx у цьому відстають. Особисто автор вважає цей тест найпоказовішим і вибирав би переможця лише з нього.
Результат не є дивним, оскільки IIS кешує вже стислий статичний контент і не пережимає його щоразу, як до нього звернулися.
Час витрачений на одного клієнта
Для оцінки продуктивності достатньо і тесту з одним одноразовим підключенням.
Наприклад, IIS завершив тестування довжиною 5000 користувачів за 40 секунд, це 123 запити в секунду.
Нижче наведено час до повної передачі контенту сайту. Це частка запитів, виконаних у певний час. У нашому випадку 80% всіх запитів було оброблено за 8мс на IIS і за 4.5мс на Apache та Nginx, а інтервал до 8 мілісекунд виконалися 98% усіх запитів на Apache та Nginx.
Час, за який 5000 запитів було опрацьовано:
Час, за який 5000 запитів було опрацьовано:
Якщо у вас є віртуальна машина з 3.5Ггц ЦП та 8 ядрами, то вибирайте те, що хочете. Всі веб-сервери дуже схожі в цьому тестуванні. Про те, який веб-сервер вибрати для кожного хоста поговоримо нижче.
Коли йдеться трохи більш реальної ситуації, всі веб-сервери йдуть ніс до носа.
Пропускна здатність:
Графік затримок кількості одночасних підключень. Рівніше та нижче – краще. Останні 2% були викинуті з графіків тому, що вони зроблять їх нечитаними.
Тепер розглянемо варіант, де сервер розміщується на віртуальному хостингу. Візьмемо 4 ядра по 2.2ГГц та одне ядро на 1.8Ггц.
Як масштабуються
Якщо ви коли-небудь бачили, як виглядають ВАХ електровакуумних тріодів, пентодів і так далі, ці графіки будуть вам знайомі. Саме це ми й намагаємось упіймати – насичення. Межа, коли скільки ядер не кидай, зростання продуктивності не буде помітним.
Раніше весь челенж полягав у тому, щоб обробити 98% запитів, маючи найменшу затримку за всіма запитами, як можна тримати криву. Тепер за допомогою побудови іншої кривої знайдемо оптимальну робочу точку для кожного із серверів.
Для цього візьмемо показник Requests per second (RPR). По горизонталі частота, по вертикалі кількість запитів, оброблених за секунду, лінії – кількість ядер.
Показана кореляція, наскільки добре Nginx обробляє запити один за одним. 8 ядер у такому тестуванні показують себе краще.
На цьому графіку чудово видно, наскільки краще (не багато) Nginx працює на одному ядрі. Якщо у вас Nginx, варто задуматися про зменшення кількості ядер до одного, якщо ви хостите лише статику.
IIS хоч і має найнижчий TTFB на думку DevTools в Chrome, примудряється програти і Nginx і Apache у серйозній боротьбі зі стрес-тестом від Apache Foundation.
Уся кривизна графіків відтворюється залізно.
Свого роду висновок:
Так, Apache залізно працює гірше на 1 та 8 ядрах, а на 4 працює трохи краще.
Так, Nginx на 8 ядрах краще обробляє запити один за одним, на 1 і 4 ядрах і гірше працює, коли з'єднань багато.
Так, IIS воліє 4 ядра для багатопотокового навантаження і віддає перевагу 8 ядер для однопотокового. Зрештою IIS виявився трохи швидше за всіх на 8 ядрах під високим навантаженням, хоча всі сервери йшли врівень.
Не помилка виміру, похибка тут трохи більше +-1мс. у затримках і не більше +- 2-3 запити на секунду для RPR.
Результати, коли 8 ядер проявляють себе гірше, зовсім не дивні, багато ядер і SMT/Hyperthreading сильно погіршують продуктивність, якщо ми маємо тимчасові рамки, за які ми повинні завершити весь пайплайн.
Джерело: habr.com