За методиката разказахме в статията, в тази тестваме HTTPS, но в по-реалистични сценарии. За тестването бе получен сертификат Let’s Encrypt, включено е компресиране Brotli на 11.
Този път ще се опитаме да възпроизведем сценарий за разгръщане на сървър на VDS или като виртуална машина на хост с типичен процесор. За това установихме лимит в:
- 25% — което в превод на честота е ~ 1350МГц
- 35% - 1890МГц
- 41% — 2214МГц
- 65% — 3510МГц
Броят на едновременните свързвания намаля от 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.5Гхц ЦП и 8 ядра, изберете това, което искате. Всички уеб сървъри са много сходни в това тестване. За това кой уеб сървър да изберете за всеки хост ще говорим по-долу.
Когато става дума за малко по-реална ситуация, всички уеб сървъри са наравно.
Пропускателна способност:
График на забави от броя на едновременни свързвания. По-плавно и по-ниско – по-добре. Последните 2% бяха изключени от графиците, защото ще ги направят нечетливи.
Сега да разгледаме вариант, при който сървърът е разположен на виртуален хостинг. Нека вземем 4 ядра с 2.2GHz и едно ядро на 1.8GHz.
Как се мащабира
Ако някога сте виждали как изглеждат характеристичните криви на електровакуумни триоди, пентоди и т.н., тези графики ще ви бъдат познати. Именно това се опитваме да уловим – наситеност. Пределът, при който, независимо колко ядра добавим, растежът на производителността няма да бъде забележим.
По-рано предизвикателството беше да се обработят 98% от запитванията с възможно най-ниска латентност на всички запитвания, да се запази кривата колкото се може по-плавна. Сега с помощта на изграждането на друга крива, ще намерим оптималната работна точка за всеки от сървърите.
За тази цел ще вземем показателя Requests per second (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/Хипернишкови процесори значително влошават производителността, ако имаме времеви рамки, в които трябва да завършим целия процес.
Източник: habr.com
