Говорихме за методиката в статия, в тази тестваме HTTPS, но в по-реалистични сценарии. За тестване получихме сертификат Let's Encrypt и активирахме компресията на Brotli до 11.
Този път ще се опитаме да възпроизведем сценария за разполагане на сървър на VDS или като виртуална машина на хост със стандартен процесор. За тази цел беше определен лимит на:
- 25% - Което е еквивалентно на честота от ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Броят на еднократните връзки е намален от 500 на 1, 3, 5, 7 и 9,
Резултати:
Закъснения:
TTFB беше специално включен като отделен тест, тъй като HTTPD Tools създава нов потребител за всяка отделна заявка. Този тест все още е доста откъснат от реалността, защото потребителят все още ще кликне няколко страници и в действителност TTFP ще играе основната роля.
Първата, обикновено първата заявка след първото стартиране на виртуалната машина IIS отнема средно 120 ms.
Всички последващи заявки показват TTFP от 1.5 ms. Apache и Nginx изостават в това отношение. Лично авторът смята този тест за най-показателен и би избрал победителя само въз основа на него.
Резултатът не е изненадващ, тъй като IIS кешира вече компресираното статично съдържание и не го компресира при всеки достъп до него.
Време, изразходвано за клиент
За да оцените производителността, е достатъчен тест с 1 единична връзка.
Например IIS завърши тест на 5000 потребители за 40 секунди, което прави 123 заявки в секунда.
Графиките по-долу показват времето до пълното прехвърляне на съдържанието на сайта. Това е делът на заявките, изпълнени за даден период от време. В нашия случай 80% от всички заявки бяха обработени за 8ms на IIS и за 4.5ms на Apache и Nginx, а 8% от всички заявки на Apache и Nginx бяха изпълнени в рамките на интервал от до 98 милисекунди.
Време, през което са обработени 5000 заявки:
Време, през което са обработени 5000 заявки:
Ако имате виртуална машина с 3.5 GHz CPU и 8 ядра, тогава изберете това, което искате. Всички уеб сървъри са много сходни при това тестване. Ще говорим за това кой уеб сървър да изберете за всеки хост по-долу.
Когато става въпрос за малко по-реалистична ситуация, всички уеб сървъри вървят един срещу друг.
Пропускателна:
Графика на закъсненията спрямо броя на едновременните връзки. По-гладко и по-ниско е по-добре. Последните 2% бяха премахнати от класациите, защото биха ги направили нечетими.
Сега нека разгледаме опцията, при която сървърът се хоства на виртуален хостинг. Да вземем 4 ядра на 2.2 GHz и едно ядро на 1.8 GHz.
Как да мащабирате
Ако някога сте виждали как изглеждат характеристиките ток-напрежение на вакуумните триоди, пентоди и т.н., тези графики ще ви бъдат познати. Това се опитваме да хванем – насищане. Ограничението е, когато колкото и ядра да хвърлите, увеличението на производителността няма да бъде забележимо.
Преди цялото предизвикателство беше да се обработят 98% от заявките с най-ниската латентност за всички заявки, поддържайки кривата възможно най-плоска. Сега, като построим друга крива, ще намерим оптималната работна точка за всеки от сървърите.
За да направите това, нека вземем индикатора Заявки в секунда (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 ядра при високо натоварване, въпреки че всички сървъри бяха на ниво.
Това не е грешка при измерване, грешката тук е не повече от +-1ms. при закъснения и не повече от +- 2-3 заявки в секунда за RPR.
Резултатите, при които 8 ядра се представят по-зле, изобщо не са изненадващи, много ядра и SMT/Hyperthreading значително влошават производителността, ако имаме времева рамка, в която трябва да завършим целия конвейер.
Източник: www.habr.com