Wy prate oer de metodyk yn artikel, yn dizze test wy HTTPS, mar yn mear realistyske senario. Foar testen hawwe wy in Let's Encrypt-sertifikaat krigen en Brotli-kompresje ynskeakele nei 11.
Dizze kear sille wy besykje it senario te reprodusearjen fan in tsjinner op in VDS of as in firtuele masine op in host mei in standert prosessor. Foar dit doel waard in limyt ynsteld op:
- 25% - Wat is lykweardich oan in frekwinsje fan ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
It oantal ienmalige ferbinings is fermindere fan 500 nei 1, 3, 5, 7 en 9,
Resultaten:
Fertragingen:
TTFB waard spesifyk opnommen as in aparte test, om't HTTPD-ark in nije brûker makket foar elk yndividueel fersyk. Dizze test is noch altyd frij los fan 'e realiteit, om't de brûker noch in pear siden sil klikke, en yn' e realiteit sil TTFP de haadrol spylje.
It earste, oer it algemien it alderearste fersyk nei de earste start fan 'e IIS firtuele masine nimt gemiddeld 120 ms.
Alle folgjende oanfragen litte in TTFP fan 1.5 ms sjen. Apache en Nginx bliuwe efter yn dit ferbân. Persoanlik beskôget de auteur dizze test as it meast iepenbierend en soe de winner allinich op basis dêrfan kieze.
It resultaat is net ferrassend, om't IIS-caches al komprimearre statyske ynhâld hawwe en it net elke kear komprimearret as it tagong wurdt.
Tiid bestege per klant
Om prestaasjes te evaluearjen is in test mei 1 inkele ferbining genôch.
Bygelyks, IIS foltôge in test fan 5000 brûkers yn 40 sekonden, dat is 123 oanfragen per sekonde.
De grafiken hjirûnder litte de tiid sjen oant de side-ynhâld folslein is oerdroegen. Dit is it oanpart fan oanfragen foltôge yn in bepaalde tiid. Yn ús gefal waarden 80% fan alle oanfragen ferwurke yn 8ms op IIS en yn 4.5ms op Apache en Nginx, en 8% fan alle oanfragen op Apache en Nginx waarden foltôge binnen in ynterval fan maksimaal 98 millisekonden.
Tiid wêryn 5000 oanfragen waarden ferwurke:
Tiid wêryn 5000 oanfragen waarden ferwurke:
As jo in firtuele masine hawwe mei in 3.5GHz CPU en 8 kearnen, kies dan wat jo wolle. Alle webservers binne heul gelyk yn dizze testen. Wy sille hjirûnder prate oer hokker webserver te kiezen foar elke host.
As it giet om in wat mear realistyske situaasje, geane alle webservers kop oan kop.
Trochslach:
Grafyk fan fertragingen tsjin it oantal simultane ferbinings. Smoother en leger is better. De lêste 2% waarden fan 'e hitlisten fuortsmiten, om't se se ûnlêsber meitsje soene.
Litte wy no de opsje beskôgje wêr't de server wurdt host op firtuele hosting. Litte wy 4 kearnen nimme op 2.2 GHz en ien kearn op 1.8 GHz.
Hoe te skaaljen
As jo oait sjoen hawwe hoe't de hjoeddeistige-spanningskaaimerken fan fakuümtriodes, pentodes, ensfh. Dit is wat wy besykje te fangen - sêding. De limyt is wannear't gjin saak hoefolle kearnen jo smite, de prestaasjesferheging sil net merkber wêze.
Earder wie de hiele útdaging om 98% fan oanfragen te ferwurkjen mei de leechste latency foar alle oanfragen, en de kromme sa flak mooglik te hâlden. No, troch in oare kromme te bouwen, sille wy it optimale bestjoeringspunt fine foar elk fan 'e servers.
Om dit te dwaan, litte wy de yndikator foar fersiken per sekonde (RPR) nimme. Horizontaal is de frekwinsje, fertikaal is it oantal oanfragen ferwurke per sekonde, rigels binne it oantal kearnen.
Toant in korrelaasje fan hoe goed Nginx fersiken ien nei de oare ferwurket. 8 kearnen prestearje better yn dizze test.
Dizze grafyk lit dúdlik sjen hoefolle better (net folle) Nginx wurket op ien kearn. As jo Nginx hawwe, moatte jo beskôgje it oantal kearnen te ferminderjen nei ien as jo allinich statyske hostje.
IIS, hoewol it de leechste TTFB hat neffens DevTools yn Chrome, slagget te ferliezen oan sawol Nginx as Apache yn in serieuze striid mei de stresstest fan 'e Apache Foundation.
Alle kromming fan 'e grafiken wurdt reprodusearre mei izer beklaaid.
In soarte fan konklúzje:
Ja, Apache wurket minder op 1 en 8 kearnen, mar wurket in bytsje better op 4.
Ja, Nginx op 8 kearnen ferwurket fersiken better ien nei de oare, op 1 en 4 kearnen, en wurket slimmer as d'r in protte ferbiningen binne.
Ja, IIS foarkar 4 kearnen foar multi-threaded workloads en leaver 8 kearnen foar single-threaded workloads. Uteinlik wie IIS wat rapper as elkenien op 8 kearnen ûnder hege lading, hoewol alle servers op par wiene.
Dit is gjin mjitflater, de flater hjir is net mear as +-1ms. yn fertragingen en net mear as +- 2-3 fersiken per sekonde foar RPR.
De resultaten dêr't 8 kearnen minder prestearje binne hielendal net ferrassend, in protte kearnen en SMT / Hyperthreading degradearje de prestaasjes sterk as wy in tiidframe hawwe wêryn wy de heule pipeline moatte foltôgje.
Boarne: www.habr.com