Vi talte om metoden i artikel, i denne tester vi HTTPS, men i mere realistiske scenarier. Til test fik vi et Let's Encrypt-certifikat og aktiverede Brotli-komprimering til 11.
Denne gang vil vi forsøge at gengive scenariet med at implementere en server på en VDS eller som en virtuel maskine på en vært med en standardprocessor. Til dette formål blev der fastsat en grænse til:
- 25% - Hvilket svarer til en frekvens på ~ 1350 MHz
- 35 % -1890 MHz
- 41 % - 2214 MHz
- 65 % - 3510 MHz
Antallet af engangsforbindelser er reduceret fra 500 til 1, 3, 5, 7 og 9,
resultater:
Forsinkelser:
TTFB blev specifikt inkluderet som en separat test, fordi HTTPD Tools opretter en ny bruger for hver enkelt anmodning. Denne test er stadig ret løsrevet fra virkeligheden, fordi brugeren stadig vil klikke et par sider, og i virkeligheden vil TTFP spille hovedrollen.
Den første, generelt den allerførste anmodning efter den første start af den virtuelle IIS-maskine, tager i gennemsnit 120 ms.
Alle efterfølgende anmodninger viser en TTFP på 1.5 ms. Apache og Nginx halter bagefter i denne henseende. Personligt betragter forfatteren denne test som den mest afslørende og ville kun vælge vinderen baseret på den.
Resultatet er ikke overraskende, da IIS cacher allerede komprimeret statisk indhold og ikke komprimerer det, hver gang det tilgås.
Tidsforbrug pr. klient
For at evaluere ydeevnen er en test med 1 enkelt forbindelse tilstrækkelig.
For eksempel gennemførte IIS en test af 5000 brugere på 40 sekunder, hvilket er 123 anmodninger i sekundet.
Graferne nedenfor viser tiden, indtil webstedets indhold er fuldstændigt overført. Dette er andelen af forespørgsler, der er gennemført på et givet tidspunkt. I vores tilfælde blev 80 % af alle anmodninger behandlet i 8 ms på IIS og i 4.5 ms på Apache og Nginx, og 8 % af alle anmodninger på Apache og Nginx blev gennemført inden for et interval på op til 98 millisekunder.
Tid, hvor 5000 anmodninger blev behandlet:
Tid, hvor 5000 anmodninger blev behandlet:
Hvis du har en virtuel maskine med en 3.5 GHz CPU og 8 kerner, så vælg hvad du vil have. Alle webservere er meget ens i denne test. Vi taler om, hvilken webserver du skal vælge for hver vært nedenfor.
Når det kommer til en lidt mere realistisk situation, går alle webservere på hovedet.
gennemløb:
Graf over forsinkelser i forhold til antallet af samtidige forbindelser. Glattere og lavere er bedre. De sidste 2 % blev fjernet fra diagrammerne, fordi de ville gøre dem ulæselige.
Lad os nu overveje muligheden, hvor serveren hostes på virtuel hosting. Lad os tage 4 kerner ved 2.2 GHz og en kerne ved 1.8 GHz.
Sådan skalerer du
Hvis du nogensinde har set, hvordan strømspændingsegenskaberne for vakuumtrioder, pentoder og så videre ser ud, vil disse grafer være bekendte for dig. Det er det, vi forsøger at fange - mætning. Grænsen er, når uanset hvor mange kerner du kaster, vil præstationsstigningen ikke være mærkbar.
Tidligere var hele udfordringen at behandle 98 % af anmodningerne med den laveste latens for alle anmodninger, og holde kurven så flad som muligt. Nu, ved at konstruere en anden kurve, vil vi finde det optimale driftspunkt for hver af serverne.
For at gøre dette, lad os tage RPR-indikatoren (Requests per second). Vandret er frekvensen, lodret er antallet af anmodninger behandlet pr. sekund, linjer er antallet af kerner.
Viser en sammenhæng mellem, hvor godt Nginx behandler anmodninger efter hinanden. 8 kerner klarer sig bedre i denne test.
Denne graf viser tydeligt, hvor meget bedre (ikke meget) Nginx fungerer på en enkelt kerne. Hvis du har Nginx, bør du overveje at reducere antallet af kerner til én, hvis du kun hoster statiske.
IIS, selvom det har den laveste TTFB ifølge DevTools i Chrome, formår at tabe til både Nginx og Apache i en seriøs kamp med stresstesten fra Apache Foundation.
Al kurvatur af graferne er gengivet jernbeklædt.
En slags konklusion:
Ja, Apache virker dårligere på 1 og 8 kerner, men fungerer lidt bedre på 4.
Ja, Nginx på 8 kerner behandler anmodninger bedre den ene efter den anden, på 1 og 4 kerner, og fungerer dårligere, når der er mange forbindelser.
Ja, IIS foretrækker 4 kerner til flertrådede arbejdsbelastninger og foretrækker 8 kerner til enkelttrådede arbejdsbelastninger. I sidste ende var IIS lidt hurtigere end alle andre på 8 kerner under høj belastning, selvom alle servere var på niveau.
Dette er ikke en målefejl, fejlen her er ikke mere end +-1ms. i forsinkelser og ikke mere end +- 2-3 anmodninger i sekundet for RPR.
Resultaterne, hvor 8 kerner klarer sig dårligere, er slet ikke overraskende, mange kerner og SMT/Hyperthreading forringer ydeevnen kraftigt, hvis vi har en tidsramme, hvor vi skal færdiggøre hele pipelinen.
Kilde: www.habr.com