Vi har talt om metoden i artiklen, i denne tester vi HTTPS, men under mere realistiske scenarier. For testningen blev et Letâs Encrypt certifikat opnĂ„et, og Brotli-komprimering blev aktiveret pĂ„ 11.
Denne gang vil vi forsÞge at genskabe et scenarie for implementering af en server pÄ VDS eller som en virtuel maskine pÄ en vÊrt med en standardprocessor. Til dette blev der sat en grÊnse pÄ:
- 25% â hvilket svarer til en frekvens pĂ„ ~ 1350MHz
- 35% -1890MHz
- 41% â 2214MHz
- 65% â 3510MHz
Antallet af samtidige forbindelser blev reduceret fra 500 til 1, 3, 5, 7 og 9,
Resultater:
Forsinkelser:
TTFB blev specielt taget ud som en separat test, fordi HTTPD-vÊrktÞjer skaber som om en ny bruger for hver enkelt anmodning. Denne test er stadig relativt langt fra virkeligheden, da en bruger stadig vil klikke pÄ et par sider, og i praksis vil TTFP spille den stÞrste rolle.
Den fĂžrste, ja, den allerfĂžrste anmodning efter den fĂžrste opstart af den virtuelle maskine IIS tager i gennemsnit 120 ms.
Alle efterfÞlgende anmodninger viser TTFP pÄ 1,5 ms. Apache og Nginx halter bagefter. Forfatteren mener personligt, at denne test er den mest sigende, og han ville kun vÊlge en vinder baseret pÄ den.
Resultatet er ikke overraskende, da IIS cachelagrer allerede komprimeret statisk indhold og ikke komprimerer det hver gang, der rettes henvendelse til det.
Tid brugt pÄ en enkelt kunde
For at vurdere ydeevnen er en test med 1 samtidig forbindelse tilstrĂŠkkelig.
For eksempel afsluttede IIS testen med 5000 brugere pÄ 40 sekunder, som svarer til 123 anmodninger pr. sekund.
I diagrammerne nedenfor er tiden til fuldstÊndig overfÞrsel af webstedets indhold angivet. Dette er andelen af anmodninger udfÞrt inden for en bestemt tid. I vores tilfÊlde blev 80% af alle anmodninger behandlet pÄ 8 ms pÄ IIS og 4,5 ms pÄ Apache og Nginx, mens intervallet op til 8 millisekunder blev udfÞrt af 98% af alle anmodninger pÄ Apache og Nginx.
Tid, det tog at behandle 5000 anmodninger:
Tid, det tog at behandle 5000 anmodninger:
Hvis du har en virtuel maskine med en 3,5 GHz CPU og 8 kerner, sÄ vÊlg det, du vil. Alle webservere er meget lignende i denne test.
NÄr det handler om en lidt mere realistisk situation, er alle webservere tÊt pÄ hinanden.
GennemstrĂžmning:
Diagram over forsinkelser i forhold til antallet af samtidige forbindelser. Fladere og lavere â bedre. De sidste 2% blev fjernet fra diagrammerne, fordi de ville gĂžre dem ulĂŠselige.
Lad os nu overveje en mulighed, hvor serveren er placeret pÄ et virtuelt hosting. Vi tager 4 kerner med 2,2 GHz og en kerne med 1,8 GHz.
Hvordan skalerer man
Hvis du nogensinde har set, hvordan karakteristikkerne for elektrovakuumtrioder, pentoder osv. ser ud, vil disse grafer vĂŠre bekendte for dig. Dette er prĂŠcis det, vi forsĂžger at fange â mĂŠtning. GrĂŠnsen, hvor meget du end lĂŠgger kerner til, vil ydelsesforĂžgelsen ikke vĂŠre synlig.
Tidligere bestod hele udfordringen i at behandle 98% af forespÞrgslerne med den lavest mulige forsinkelse pÄ alle forespÞrgsler, og holde kurven sÄ jÊvn som muligt. Nu, ved at bygge en anden kurve, vil vi finde det optimale arbejdspunkt for hver af serverne.
Til dette vil vi tage mĂ„lingen Requests per second (RPR). PĂ„ den horisontale akse frekvens, pĂ„ den vertikale akse â antallet af forespĂžrgsler behandlet pr. sekund, linjerne â antal kerner.
Korrelationsgraden af, hvor godt Nginx behandler forespĂžrgsler Ă©n ad gangen, er vist. 8 kerner viser sig at vĂŠre bedre i denne test.
PÄ denne graf er det tydeligt, hvor meget bedre (dog ikke voldsomt) Nginx fungerer pÄ én kerne. Hvis du bruger Nginx, kan det vÊre en god idé at overveje at reducere antallet af kerner til én, hvis du kun hoster statisk indhold.
Selvom IIS har den laveste TTFB ifÞlge DevTools i Chrome, formÄr den stadig at tabe til bÄde Nginx og Apache i en seriÞs kamp mod stresstest fra Apache Foundation.
Hele grafens krumning reproduceres prĂŠcist.
En slags konklusion:
Ja, Apache fungerer dÄrere pÄ 1 og 8 kerner, men lidt bedre pÄ 4.
Ja, Nginx behandler forespÞrgsler bedre med 8 kerner enkeltvis, mens det fungerer vÊrre med 1 og 4 kerner, nÄr der er mange forbindelser.
Ja, IIS foretrÊkker 4 kerner til multitrÄdet belastning og 8 kerner til enkelttrÄdet. I sidste ende viste IIS sig at vÊre lidt hurtigere end alle pÄ 8 kerner under hÞj belastning, selvom alle servere var pÄ niveau.
Dette er ikke en mÄlingsfejl; variansen er ikke mere end ±1 ms i forsinkelser og ikke mere end ±2-3 forespÞrgsler pr. sekund for RPR.
Resultaterne, nÄr 8 kerner prÊsterer dÄrligere, er slet ikke overraskende; mange kerner og SMT/Hyperthreading forringer ydeevnen voldsomt, hvis vi har tidsrammer, inden for hvilke vi skal afslutte hele pipeline.
Kilde: habr.com
