В тази статия ще опитаме да се занимаваме с реверс-инжиниринг. Ще надникнем под капака на всеки от уеб сървърите с нашите мръсни ръце, експлоатирайки ги по начин, по който никой друг не би го направил.
Тестът е измерване на сферичен кон в вакуум, нищо повече от данни, които бяха получени и сега не знаем какво да правим с тях.
Методика
Операционната система за 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@5400MHz, което означава, че сървърът, получил ограничение от 10%, получава около 540MHz на ядро.
Тестът за TTFB беше проведен при първичното зареждане на сървъра и измерен с помощта на DevTools. След като резултатът беше получен, сървърът беше изключен и върнат на предишната контрольна точка, за да се изключи всякакво кэширане.
Тестовият оператор и уеб сървърът бяха на един и същ хост и на един и същ виртуален комутатор.
За мигновена оценка на дисковата подсистема, резултатите от бенчмарка ATTO и CrystalDiskMark, за да има представа за тесните места.
Данните са получени от виртуална машина:
Резултати:
TTFB:
Средният TTFB при IIS е най-нисък, 0.5ms, в сравнение с 1.4ms при Apache и 4ms при Nginx.
Пропускателна способност:
Първо, ще разгледаме колко добре всеки от сървърите се мащабира по брой ядра.
На графиката е представен брой запитвания на тестера към уеб сървъра и латентността. Ясно се вижда, че NGINX е обработил 98% от всички запитвания, предоставяйки сайта за 20ms или по-малко. IIS и Apache обработиха последните 5% от всички запитвания за 76ms и 14ms съответно.
На графиката е показано средното време за обработка на една заявка по време на стрес теста.
Както може да се забележи от графиките, 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
