У цій статті ми спробуємо себе у реверс-інжинірингу, можна сказати. Ми заглянемо своїми брудними руками під капот кожного з веб-серверів, експлуатуючи їх так, як ніхто ніколи не експлуатував би.
Цей тест – замір сферичного коня у вакуумі, не більше ніж дані, отримані, і ми тепер не знаємо, що з ними робити.
Методика
Як операційна система для Nginx і Apache виступає Ubuntu 18.04 LTS, для IIS Windows Server Core 2019. Усі операційні системи перед тестами отримали останні оновлення на стан 04.12.2019.
Тести проводилися виключно з HTTP. На кожному з веб-серверів крутилася та сама сторінка, безкоштовний шаблон для Jekyll від Codrops. . На кожному з веб-серверів було вимкнено стиснення gzip.
Тест пропускної спроможності проводився з Httpd-tools з аргументами:
ab -n 50000 -c 500 http://192.168.76.204:80/На сервери встановлювався ліміт 10, 5 і 1 відсоток від ядра на 8, 4 та одному ядрі. Як тестовий стенд був комп'ютер із 9900K@5400мгц, що означає, що сервер, що отримав обмеження в 10%, отримує близько 540мгц на ядро.
Тест TTFB проводився при першому завантаженні сервера і замірявся за допомогою DevTools, після отримання результату сервер вимикався і відкочувався на попередню контрольну точку, щоб унеможливити появу будь-якого роду кешів.
Тестувальник і веб-сервер знаходилися на тому самому хості і на тому самому віртуальному світчі.
Щоб одразу оцінити дискову підсистему, результати бенчмарку ATTO та CrystalDIskMark, щоб мати поняття про вузькі місця.
Дані знято з віртуальної машини:
Результати:
TTFB:
Середній TTFB у IIS найменший, 0,5мс, проти 1,4мс у Apache і 4мс у Nginx.
Пропускна здатність:
Спочатку розглянемо, наскільки добре кожен із серверів масштабується за кількістю ядер.
На графіку представлено кількість звернень тестувальника до веб-сервера та латентність. На графіку видно, що NGINX відпрацював 98% всіх звернень, віддавши сайт за 20мс і менше. IIS як і Apache останні 5% з усіх звернень відпрацювали за 76мс та 14мс відповідно.
На графіку показаний середній час обробки одного запиту під час стрес тесту.
Як можна помітити з графіків, IIS продули і Apache і Nginx, сильно сповільнюючись під високим навантаженням.
IIS явно віддав перевагу 4 ядрам перед вісьмома, показавши менші затримки на чотирьох, але так само не сильно схвалив і одне ядро.
NGINX чудово масштабується на всі 8 ядер, а для Apache, зважаючи на все, одноядерний сценарій здається найкращим вибором.
Масштабованість:
Nginx:
Тепер розглянемо масштабованість за частотою та кількістю ядер.
Тести з обмеженням 1% на 4 і 1 ядра Nginx не пройшов, вийшовши за 2000 запитів він обривав з'єднання з тестувальником.
Apache:
Apache як Nginx обробивши 2500 запитів, здався і розірвав з'єднання. Apache не пройшов тест на 8, 4 і 1 ядрах з лімітом в 1%, але крім цього не пройшов і тест на 5% обмеження на одному ядрі, що гірше ніж Nginx
IIS:
IIS під час тестів набрав гігантську чергу із запитів, але обробив кожен з них. Зважаючи на все, в ньому з коробки не встановлені таймаути на обробку запиту.
На діаграмі подано час, за який було завершено тест. Були відкинуті абсолютно абсурдні зміни тестування. З діаграми видно, наскільки IIS вимогливий до заліза і наскільки прекрасний NGINX.
Масштабованість від диска:
Nginx:
Тепер розглянемо масштабованість по частоті та кількості ядер та швидкості диска.
На цей раз Nginx не пройшов 4 тести, замість двох.
Apache:
Apache провалив однакову кількість тестів, як і минулого разу.
IIS:
IIS показує майже ідентичний графік, начебто обмежень на диск і не було. Загалом графіки у всіх серверів не сильно змінилися, а це означає, що кожен з них закешував статику в оперативну пам'ять і віддавав звідти. Тут бачимо головне вузьке місце – сам веб-сервер.
Висновки на основі цього тестування робити рано, ми ще не протестували HTTPS, компресію та HTTP/2 із живим сертифікатом від Let's Encrypt. Про це розповімо у наступній статті.
Джерело: habr.com