Разговаравме за техниката во статија, во оваа тестираме HTTPS, но во пореални сценарија. За тестирање, добивме сертификат Let's Encrypt и овозможивме компресија на Brotli на 11.
Овој пат ќе се обидеме да го репродуцираме сценариото за распоредување на сервер на VDS или како виртуелна машина на домаќин со стандарден процесор. За таа цел беше поставено ограничување на:
- 25% - што е еквивалентно на фреквенција од ~ 1350 MHz
- 35% -1890 MHz
- 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 и 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