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