Vi har talat om metoden i artikeln, i denna testar vi HTTPS, men i mer realistiska scenarier. För testerna skaffades ett certifikat frĂ„n Letâs Encrypt, och Brotli-komprimering aktiverades pĂ„ 11.
Denna gÄng försöker vi Äterskapa scenariot för att distribuera en server pÄ VDS eller som en virtuell maskin pÄ en vÀrd med en typisk processor. För detta satte vi en grÀns pÄ:
- 25% â vilket i omrĂ€knat till frekvens blir ~ 1350MHz
- 35% - 1890MHz
- 41% â 2214MHz
- 65% â 3510MHz
Antalet samtidiga anslutningar minskade frÄn 500 till 1, 3, 5, 7 och 9,
Resultat:
Fördröjningar:
TTFB (Time to First Byte) har sÀrskilt tagits ut som ett eget test, eftersom HTTPD-verktyg för varje enskild begÀran skapar en ny anvÀndare. Detta test Àr fortfarande ganska avskilt frÄn verkligheten, eftersom en anvÀndare ÀndÄ skulle klicka pÄ nÄgra sidor, och i verkligheten skulle TTFP spela en huvudroll.
Den första, faktiskt den allra första begÀran efter att den virtuella IIS-maskinen har startat, hanteras i genomsnitt pÄ 120 ms.
Alla efterföljande begÀrningar visar ett TTFP pÄ 1.5 ms. Apache och Nginx ligger efter hÀr. Författaren anser personligen att detta test Àr det mest representativa och skulle vÀlja en vinnare baserat enbart pÄ det.
Resultatet Àr inte överraskande, eftersom IIS cachar redan komprimerat statiskt innehÄll och inte komprimerar det varje gÄng det efterfrÄgas.
Tid som spenderas per kund
För att bedöma prestandan rÀcker det med ett test med 1 samtidig anslutning.
Till exempel, IIS avslutade testen med 5000 anvÀndare pÄ 40 sekunder, vilket motsvarar 123 begÀrningar per sekund.
I diagrammen nedan visas tiden tills allt innehÄll pÄ webbplatsen har överförts. Detta Àr andelen begÀrningar som utförs under en viss tid. I vÄrt fall bearbetades 80% av alla begÀrningar pÄ 8ms för IIS och 4.5ms för Apache och Nginx, medan intervallet upp till 8 millisekunder genomfördes av 98% av alla begÀrningar pÄ Apache och Nginx.
Tiden det tog att bearbeta 5000 begÀrningar:
Tiden det tog att bearbeta 5000 begÀrningar:
Om du har en virtuell maskin med 3.5GHz CPU och 8 kÀrnor, vÀlj det du vill. Alla webbservrar Àr mycket lika i denna testning. Vilken webbserver man bör vÀlja för varje vÀrd kommer vi att diskutera nedan.
NÀr det handlar om en nÄgot mer verklig situation gÄr alla webbservrar jÀmsides.
Genomströmning:
Diagram över fördröjningar vid antal samtidiga anslutningar. Ju jÀmnare och lÀgre, desto bÀttre. De sista 2% utslöts frÄn diagrammen eftersom de skulle göra dem olÀsliga.
LÄt oss nu titta pÄ alternativet dÀr servern placeras pÄ virtuell hosting. Vi tar 4 kÀrnor pÄ 2,2 GHz och en kÀrna pÄ 1,8 GHz.
Hur skalas de
Om du nĂ„gonsin har sett hur VA-kurvor för elektriska vakuumtrioder, pentoder osv. ser ut, sĂ„ kommer dessa diagram att vara bekanta för dig. Det Ă€r precis detta vi försöker fĂ„nga â mĂ€ttnaden. GrĂ€nsen dĂ€r, oavsett hur mĂ„nga kĂ€rnor du lĂ€gger till, sĂ„ kommer prestandaökningen inte att mĂ€rkas.
Tidigare gick hela utmaningen ut pÄ att bearbeta 98 % av förfrÄgningarna med minsta möjliga latens, för att sÄ jÀmnt som möjligt hÄlla kurvan. Nu, med hjÀlp av att bygga en annan kurva, kommer vi att hitta den optimala arbetspunkten för varje server.
För detta tar vi mĂ„ttet Requests per second (RPR). PĂ„ den horisontella axeln frekvensen, pĂ„ den vertikala â antalet förfrĂ„gningar som bearbetas per sekund, linjerna representerar antalet kĂ€rnor.
Det visar korrelationen av hur vÀl Nginx bearbetar förfrÄgningar en efter en. 8 kÀrnor presterar bÀttre i sÄdana tester.
I detta diagram kan man tydligt se hur mycket bÀttre (inte mycket) Nginx fungerar pÄ en kÀrna. Om du har Nginx bör du övervÀga att minska antalet kÀrnor till en, om du hostar enbart statisk data.
Ăven om IIS har den lĂ€gsta TTFB enligt DevTools i Chrome lyckas det förlora mot bĂ„de Nginx och Apache i en allvarlig kamp i stress-testet frĂ„n Apache Foundation.
All krökning av diagrammen reproduceras noggrant.
En slags slutsats:
Ja, Apache fungerar definitivt sÀmre pÄ 1 och 8 kÀrnor, men pÄ 4 kÀrnor fungerar det nÄgot bÀttre.
Ja, Nginx hanterar förfrÄgningar bÀttre en efter en pÄ 8 kÀrnor, men fungerar sÀmre pÄ 1 och 4 kÀrnor nÀr det Àr mÄnga anslutningar.
Ja, IIS föredrar 4 kÀrnor för flertrÄdad belastning och föredrar 8 kÀrnor för en-trÄdad. I slutÀndan visade sig IIS vara nÄgot snabbare Àn alla andra pÄ 8 kÀrnor under hög belastning, Àven om alla servrar var nÀra varandra.
Detta Àr inget mÀtfel, felmarginalen ligger hÀr pÄ högst ±1 ms i latens och högst ±2-3 förfrÄgningar per sekund för RPR.
Resultaten dÀr 8 kÀrnor presterar sÀmre Àr inte alls överraskande, mÄnga kÀrnor och SMT/Hyperthreading försÀmrar kraftigt prestandan om vi har tidsramar inom vilka vi mÄste avsluta hela pipeline.
KĂ€lla: habr.com
