Rääkisime metoodikast aastal Selles artiklis testime HTTPS-i, kuid realistlikumates stsenaariumides. Testimiseks hankisime Let's Encrypt sertifikaadi ja lubasime Brotli tihendamise 11-ni.
Seekord proovime reprodutseerida serveri juurutamise stsenaariumi VDS-is või tavalise protsessoriga hostis virtuaalmasinana. Selleks määrati piirmäär järgmiselt:
- 25% – mis võrdub sagedusega ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Ühekordsete ühenduste arv on vähenenud 500-lt 1, 3, 5, 7 ja 9-le,
Tulemused:
Viivitused:
TTFB lisati spetsiaalselt eraldi testina, kuna HTTPD Tools loob iga üksiku päringu jaoks uue kasutaja. See test on siiski reaalsusest üsna eemaldunud, sest kasutaja klõpsab ikkagi paar lehekülge ja tegelikkuses mängib peamist rolli TTFP.
Esimene, üldiselt kõige esimene päring pärast IIS-i virtuaalmasina esimest käivitamist, võtab keskmiselt 120 ms.
Kõik järgnevad päringud näitavad TTFP-d 1.5 ms. Apache ja Nginx on selles osas maha jäänud. Autor isiklikult peab seda testi kõige paljastavamaks ja valiks võitja ainult selle põhjal.
Tulemus pole üllatav, kuna IIS salvestab vahemällu juba tihendatud staatilise sisu ega tihenda seda iga kord, kui sellele juurde pääsete.
Kliendi kohta kulutatud aeg
Toimivuse hindamiseks piisab 1 ühe ühendusega testist.
Näiteks IIS lõpetas 5000 kasutajaga testimise 40 sekundiga, mis teeb 123 päringut sekundis.
Allolevad graafikud näitavad aega, mis kulub saidi sisu täieliku ülekandmiseni. See on teatud aja jooksul täidetud taotluste osakaal. Meie puhul töödeldi 80% kõigist päringutest IIS-is 8 ms ja Apache ja Nginxi puhul 4.5 ms ning 8% kõigist Apache ja Nginxi taotlustest täideti kuni 98 millisekundi pikkuse intervalliga.
Aeg, mille jooksul töödeldi 5000 taotlust:
Aeg, mille jooksul töödeldi 5000 taotlust:
Kui teil on 3.5 GHz protsessori ja 8 tuumaga virtuaalmasin, valige, mida soovite. Kõik veebiserverid on selles testis väga sarnased. Sellest, millist veebiserverit iga hosti jaoks valida, räägime allpool.
Kui rääkida veidi realistlikumast olukorrast, siis kõik veebiserverid lähevad vastamisi.
Läbilaskevõime:
Viivituste graafik võrreldes samaaegsete ühenduste arvuga. Siledam ja madalam on parem. Viimased 2% eemaldati graafikutest, kuna need muudaksid need loetamatuks.
Nüüd kaalume võimalust, kus serverit hostitakse virtuaalses hostimises. Võtame 4 tuuma sagedusel 2.2 GHz ja ühe tuuma sagedusel 1.8 GHz.
Kuidas skaleerida
Kui olete kunagi näinud, millised näevad välja vaakumtrioodide, pentoodide ja muu sellise voolu-pinge omadused, on need graafikud teile tuttavad. Seda me püüame tabada – küllastumist. Piir on siis, kui ükskõik kui palju südamikke viskad, ei ole jõudluse kasv märgatav.
Varem oli kogu väljakutse töödelda 98% taotlustest madalaima latentsusega kõigi päringute puhul, hoides kõvera võimalikult tasa. Nüüd, koostades teise kõvera, leiame iga serveri jaoks optimaalse tööpunkti.
Selleks võtame taotluste sekundis (RPR) indikaatori. Horisontaalne on sagedus, vertikaalne sekundis töödeldavate päringute arv, read on tuumade arv.
Näitab korrelatsiooni selle kohta, kui hästi Nginx taotlusi üksteise järel töötleb. 8 südamikku toimivad selles testis paremini.
See graafik näitab selgelt, kui palju paremini (mitte palju) Nginx ühe tuumaga töötab. Kui teil on Nginx, peaksite kaaluma tuumade arvu vähendamist ühele, kui hostite ainult staatilisi.
Kuigi IIS-il on Chrome'i DevToolsi andmetel madalaim TTFB, õnnestub see tõsises võitluses Apache Foundationi stressitestiga kaotada nii Nginxile kui ka Apache'ile.
Kõik graafikute kumerused on taasesitatud raudselt.
Mingi järeldus:
Jah, Apache töötab 1 ja 8 tuumaga kehvemini, kuid 4 tuumaga töötab veidi paremini.
Jah, 8-tuumaline Nginx töötleb päringuid üksteise järel paremini, 1- ja 4-tuumadel ning töötab halvemini, kui ühendusi on palju.
Jah, IIS eelistab mitme lõimega töökoormuste jaoks 4 tuuma ja ühe lõimega töökoormuste jaoks 8 tuuma. Lõppkokkuvõttes oli IIS suure koormuse all 8 tuumal kõigist teistest pisut kiirem, kuigi kõik serverid olid võrdsed.
See pole mõõtmisviga, siin pole viga rohkem kui +-1ms. viivitustes ja mitte rohkem kui +- 2-3 taotlust sekundis RPR jaoks.
Tulemused, kus 8 südamikku toimivad halvemini, ei ole sugugi üllatavad, paljud tuumad ja SMT/Hyperthreading halvendavad jõudlust oluliselt, kui meil on ajaraam, mille jooksul peame kogu konveieri lõpule viima.
Allikas: www.habr.com