Біз әдістеме туралы әңгімелестік Бұл мақалада біз HTTPS-ті тексереміз, бірақ нақтырақ сценарийлерде. Тестілеу үшін біз Let's Encrypt сертификатын алдық және Brotli қысуды 11-ге қостық.
Бұл жолы біз серверді VDS жүйесінде немесе стандартты процессоры бар хостта виртуалды машина ретінде орналастыру сценарийін қайта жасауға тырысамыз. Осы мақсатта шектеу қойылды:
- 25% - Бұл ~ 1350 МГц жиілікке баламалы
- 35% -1890 МГц
- 41% - 2214 МГц
- 65% - 3510 МГц
Бір реттік қосылымдар саны 500-ден 1, 3, 5, 7 және 9-ға дейін қысқартылды,
нәтижелері:
Кешігулер:
TTFB арнайы сынақ ретінде қосылды, себебі HTTPD құралдары әрбір жеке сұрау үшін жаңа пайдаланушы жасайды. Бұл сынақ әлі де шындықтан мүлдем алшақ, өйткені пайдаланушы әлі де бірнеше бетті басады, ал шын мәнінде TTFP басты рөлді атқарады.
Бірінші, әдетте, IIS виртуалды машинасын бірінші іске қосқаннан кейінгі бірінші сұрау орта есеппен 120 мс алады.
Барлық кейінгі сұраулар 1.5 мс TTFP көрсетеді. Apache және Nginx бұл жағынан артта қалды. Жеке автор бұл сынақты ең ашық деп санайды және жеңімпазды тек соған қарап таңдайды.
Нәтиже таңқаларлық емес, өйткені IIS сығылған статикалық мазмұнды кэштейді және оған қол жеткізген сайын оны қыспайды.
Бір клиентке жұмсалған уақыт
Өнімділікті бағалау үшін 1 жалғыз қосылымы бар сынақ жеткілікті.
Мысалы, IIS 5000 секундта 40 пайдаланушыны тестілеуді аяқтады, бұл секундына 123 сұрауды құрайды.
Төмендегі графиктер сайт мазмұны толығымен тасымалданғанша уақытты көрсетеді. Бұл белгілі бір уақытта орындалған сұраулардың үлесі. Біздің жағдайда барлық сұраулардың 80% IIS жүйесінде 8 мс және Apache және Nginx жүйелерінде 4.5 мс өңделді, ал Apache және Nginx жүйелеріндегі барлық сұраулардың 8% 98 миллисекундқа дейінгі аралықта орындалды.
5000 сұрау өңделген уақыт:
5000 сұрау өңделген уақыт:
Егер сізде 3.5 ГГц процессоры және 8 ядросы бар виртуалды машина болса, қалағаныңызды таңдаңыз. Бұл сынақта барлық веб-серверлер өте ұқсас. Төменде әрбір хост үшін қандай веб-серверді таңдау керектігі туралы айтатын боламыз.
Сәл шынайырақ жағдайға келетін болсақ, барлық веб-серверлер бір-бірімен бетпе-бет келеді.
Өткізу мүмкіндігі:
Бір уақыттағы қосылымдар санына қарсы кідіріс графигі. Тегіс және төменірек болғаны жақсы. Соңғы 2% диаграммалардан жойылды, себебі олар оларды оқылмайды.
Енді сервер виртуалды хостингте орналасатын опцияны қарастырайық. 4 ГГц жиілікте 2.2 ядроны және 1.8 ГГц жиілікте бір ядроны алайық.
Қалай масштабтауға болады
Егер сіз вакуумдық триодтардың, пентодтардың және т.б. ток кернеуінің сипаттамалары қандай болатынын көрген болсаңыз, бұл графиктер сізге таныс болады. Міне, біз ұстауға тырысамыз - қанықтылық. Шектеу - сіз қанша ядро тастасаңыз да, өнімділіктің жоғарылауы байқалмайды.
Бұрын барлық мәселе қисық сызықты мүмкіндігінше тегіс етіп, барлық сұраулар үшін ең аз кідіріспен сұраулардың 98% өңдеу болатын. Енді басқа қисық сызықты салу арқылы біз серверлердің әрқайсысы үшін оңтайлы жұмыс нүктесін табамыз.
Ол үшін секундына сұраныс (RPR) индикаторын алайық. Көлденең – жиілік, тік – секундына өңделетін сұраулар саны, жолдар – өзектер саны.
Nginx сұраныстарды бірінен соң бірін қаншалықты жақсы өңдейтінінің корреляциясын көрсетеді. Бұл сынақта 8 ядро жақсырақ жұмыс істейді.
Бұл график Nginx бір ядрода қаншалықты жақсы (көп емес) жұмыс істейтінін анық көрсетеді. Егер сізде Nginx болса, тек статикалық ядроларды орналастырсаңыз, ядролар санын біреуге дейін азайтуды қарастырған жөн.
IIS, Chrome-дағы DevTools-қа сәйкес ең төменгі TTFB-ге ие болса да, Apache Foundation стресс-тесті арқылы ауыр күресте Nginx пен Apache-ден жеңіліп қалады.
Графиктердің барлық қисықтары темірмен қапталған.
Қандай да бір қорытынды:
Иә, Apache 1 және 8 ядроларда нашар жұмыс істейді, бірақ 4-те сәл жақсырақ жұмыс істейді.
Иә, 8 ядродағы Nginx сұрауларды бірінен соң бірі, 1 және 4 ядроларда жақсы өңдейді және көптеген қосылымдар болған кезде нашар жұмыс істейді.
Иә, IIS көп ағынды жұмыс жүктемелері үшін 4 ядроны және бір ағынды жұмыс жүктемелері үшін 8 ядроны артық көреді. Сайып келгенде, IIS жоғары жүктеме кезінде 8 ядродағы басқаларға қарағанда жылдамырақ болды, дегенмен барлық серверлер тең болды.
Бұл өлшеу қатесі емес, мұндағы қате +-1мс аспайды. кідірістерде және RPR үшін секундына +- 2-3 сұраныстан аспайды.
8 ядроның нашар жұмыс істейтін нәтижелері таңқаларлық емес, көптеген ядролар мен SMT/Hyperthreading өнімділікті айтарлықтай төмендетеді, егер бізде бүкіл құбырды аяқтауға тура келетін уақыт шеңбері болса.
Ақпарат көзі: www.habr.com