Аб методыцы мы расказвалі ў артыкулы, у гэтай мы тэстуем 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/8мс на Apache і Nginx, а інтэрвал да 98 мілісекунд выканаліся XNUMX% усіх запытаў на Apache і Nginx.
Час, за які 5000 запытаў былі апрацаваны:
Час, за які 5000 запытаў былі апрацаваны:
Калі ў вас ёсць віртуальная машына з 3.5Ггц ЦП і 8 ядрамі, то выбірайце тое, што хочаце. Усе вэб серверы вельмі падобныя ў дадзеным тэсціраванні. Аб тым, які вэб сервер абраць для кожнага хаста пагаворым ніжэй.
Калі гаворка ідзе крыху больш рэальнай сітуацыі, усе вэб серверы ідуць нос да носа.
Прапускная здольнасць:
Графік затрымак ад колькасці адначасовых падлучэнняў. Роўней і ніжэй - лепш. Апошнія 2% былі выкінуты з графікаў таму, што яны зробяць іх нечытэльнымі.
Цяпер разгледзім варыянт, дзе сервер размяшчаецца на віртуальным хостынгу. Возьмем 4 ядры па 2.2Ггц і адно ядро на 1.8Ггц.
Як маштабуюцца
Калі вы калі-небудзь бачылі, як выглядаюць ВАХ электравакуумных трыёдаў, пентодаў і гэтак далей, гэтыя графікі будуць для вас знаёмыя. Менавіта гэта мы і спрабуем злавіць - насычэнне. Мяжа, калі колькі ядраў не кідай, рост прадукцыйнасці не будзе прыкметны.
Раней увесь челенж складаўся ў тым, каб апрацаваць 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 ядрах пад высокай нагрузкай, хоць усе серверы ішлі нараўне.
Гэта не памылка вымярэння, хібнасць тут не больш за +-1мс. у затрымках і не больш за +- 2-3 запыту ў секунду для RPR.
Вынікі, калі 8 ядраў праяўляюць сябе горш, зусім не дзіўныя, шмат ядраў і SMT/Hyperthreading моцна пагаршаюць прадукцыйнасць, калі ў нас ёсць часавыя рамкі, за якія мы павінны завяршыць увесь пайплайн.
Крыніца: habr.com