Во оваа статија ќе се обидеме со обратно инженерство, може да се каже. Ќе ги ставиме нашите валкани раце под капакот на секој веб-сервер, искористувајќи ги на начини на кои никој никогаш не би ги искористил.
Овој тест е мерење на сферичен коњ во вакуум, ништо повеќе од податоци кои се добиени, а сега не знаеме што да правиме со него.
Методологија
Оперативниот систем за Nginx и Apache е Ubuntu 18.04 LTS, за IIS Windows Server Core 2019. Сите оперативни системи ги добија најновите ажурирања од 4 декември 2019 година, пред тестирањето.
Тестовите беа извршени исклучиво преку HTTP. Секој веб-сервер работи на истата страница, бесплатен Jekyll шаблон од Codrops. . На секој веб-сервер беше оневозможена компресија на gzip.
Пропусниот тест беше направен со Httpd-алатки со аргументите:
ab -n 50000 -c 500 http://192.168.76.204:80/Серверите беа ограничени на 10, 5 и 1 процент од јадрото на 8, 4 и едно јадро. Клупата за тестирање беше компјутер со 9900K@5400MHz, што значи дека серверот што добива ограничување од 10% добива околу 540 MHz по јадро.
Тестот TTFB беше извршен кога серверот првпат се подигна и се мери со помош на DevTools по добивањето на резултатот, серверот беше исклучен и вратен назад на претходната контролна точка за да се елиминира појавата на секаков вид кеш.
Тестерот и веб-серверот беа на истиот хост и на истиот виртуелен прекинувач.
За веднаш да се процени потсистемот на дискот, резултатите од одредниците ATTO и CrystalDIskMark со цел да се има идеја за тесните грла.
Податоци земени од виртуелната машина:
Резултати:
TTFB:
Просечниот TTFB за IIS е најмал, 0,5ms, наспроти 1,4ms за Apache и 4ms за Nginx.
Пропусна моќност:
Прво, да погледнеме колку добро се скали секој сервер врз основа на бројот на јадра.
Графиконот го прикажува бројот на повици од тестерот до веб-серверот и доцнењето. Графиконот покажува дека NGINX обработил 98% од сите барања, доставувајќи ја страницата за 20 ms или помалку. IIS, како и Apache, ги заврши последните 5% од сите повици за 76ms и 14ms, соодветно.
Графиконот го прикажува просечното време на обработка за едно барање за време на стрес тест.
Како што можете да видите од графиконите, IIS ги уништи и Apache и Nginx, значително забавувајќи се под големо оптоварување.
IIS јасно претпочиташе 4 јадра над XNUMX, покажувајќи пониски латенции на XNUMX, но исто така не фаворизираше силно едно јадро.
NGINX добро се скалира низ сите 8 јадра, а за Apache, сценариото со едно јадро се чини дека е најдобриот избор.
Приспособливост:
nginx:
Сега да ја разгледаме приспособливоста во однос на фреквенцијата и бројот на јадра.
Nginx не помина тестови со ограничување од 1% за 4 и 1 јадра кога надмина 2000 барања, ја прекина врската со тестерот.
Apache:
Apache, како и Nginx, откако обработи 2500 барања, се откажа и ја затвори врската. Apache падна на тестот на 8, 4 и 1 јадра со ограничување од 1%, но исто така падна на тестот со ограничување од 5% на едно јадро, што е полошо од Nginx
IIS:
За време на тестовите, IIS акумулираше огромна редица барања, но го обработи секое од нив. Очигледно, надвор од кутијата нема поставени временски рокови за обработка на барањата.
Табелата го прикажува времето потребно за да се заврши тестот. Целосно апсурдни конфигурации за тестирање беа отфрлени. Дијаграмот покажува колку бара IIS кога станува збор за хардвер, и колку е прекрасен NGINX.
Приспособливост од диск:
nginx:
Сега да ја разгледаме приспособливоста во однос на фреквенцијата и бројот на јадра и брзината на дискот.
Овој пат Nginx падна на 4 теста наместо два.
Apache:
Apache не успеа ист број на тестови како и минатиот пат.
IIS:
IIS покажува речиси идентичен график, како да нема ограничувања на дискот. Генерално, графиката на сите сервери не се промени многу, што значи дека секој од нив кеширал статички податоци во RAM меморијата и ги сервирал од таму. Овде го гледаме главното тесно грло - самиот веб-сервер.
Премногу е рано да се извлечат заклучоци врз основа на ова тестирање, сè уште не сме тестирале HTTPS, компресија и HTTP/2 со сертификат во живо од Let's Encrypt. Ќе зборуваме за ова во следната статија.
Извор: www.habr.com
