Vi snakket om teknikken i artikkelen, i denne tester vi HTTPS, men i mer realistiske scenarier. For testing fikk vi et Let's Encrypt-sertifikat og aktiverte Brotli-komprimering til 11.
Denne gangen vil vi prøve å reprodusere scenariet med å distribuere en server på en VDS eller som en virtuell maskin på en vert med en standard prosessor. For dette formålet ble det satt en grense til:
- 25 % - Noe som tilsvarer en frekvens på ~ 1350 MHz
- 35 % -1890 MHz
- 41 % - 2214 MHz
- 65 % - 3510 MHz
Antall engangsforbindelser er redusert fra 500 til 1, 3, 5, 7 og 9,
Resultater:
Forsinkelser:
TTFB ble spesifikt inkludert som en egen test, fordi HTTPD Tools oppretter en ny bruker for hver enkelt forespørsel. Denne testen er fortsatt ganske løsrevet fra virkeligheten, fordi brukeren fortsatt vil klikke et par sider, og i realiteten vil TTFP spille hovedrollen.
Den første, vanligvis den aller første forespørselen etter den første starten av den virtuelle IIS-maskinen, tar i gjennomsnitt 120 ms.
Alle påfølgende forespørsler viser en TTFP på 1.5 ms. Apache og Nginx henger etter i denne forbindelse. Personlig anser forfatteren denne testen som den mest avslørende og vil kun velge vinneren basert på den.
Resultatet er ikke overraskende siden IIS cacher allerede komprimert statisk innhold og ikke komprimerer det hver gang det åpnes.
Tid brukt per klient
For å evaluere ytelsen er en test med 1 enkelt tilkobling tilstrekkelig.
For eksempel fullførte IIS en test av 5000 brukere på 40 sekunder, som er 123 forespørsler per sekund.
Grafene nedenfor viser tiden før innholdet på nettstedet er fullstendig overført. Dette er andelen av forespørsler som er fullført på et gitt tidspunkt. I vårt tilfelle ble 80 % av alle forespørsler behandlet i 8 ms på IIS og i 4.5 ms på Apache og Nginx, og 8 % av alle forespørsler på Apache og Nginx ble fullført innen et intervall på opptil 98 millisekunder.
Tiden da 5000 forespørsler ble behandlet:
Tiden da 5000 forespørsler ble behandlet:
Hvis du har en virtuell maskin med en 3.5 GHz CPU og 8 kjerner, så velg hva du vil ha. Alle webservere er veldig like i denne testen. Vi snakker om hvilken webserver du skal velge for hver vert nedenfor.
Når det kommer til en litt mer realistisk situasjon, går alle webservere mot hverandre.
gjennomløp:
Graf over forsinkelser kontra antall samtidige tilkoblinger. Mykere og lavere er bedre. De siste 2 % ble fjernet fra listene fordi de ville gjøre dem uleselige.
La oss nå vurdere alternativet der serveren er vert for virtuell hosting. La oss ta 4 kjerner på 2.2 GHz og en kjerne på 1.8 GHz.
Hvordan skalere
Hvis du noen gang har sett hvordan strømspenningsegenskapene til vakuumtrioder, pentoder og så videre ser ut, vil disse grafene være kjent for deg. Det er dette vi prøver å fange - metning. Grensen er når uansett hvor mange kjerner du kaster, vil ytelsesøkningen ikke merkes.
Tidligere var hele utfordringen å behandle 98 % av forespørslene med lavest ventetid for alle forespørsler, og holde kurven så flat som mulig. Nå, ved å konstruere en annen kurve, vil vi finne det optimale driftspunktet for hver av serverne.
For å gjøre dette, la oss ta RPR-indikatoren (Requests per second). Horisontal er frekvensen, vertikal er antall forespørsler behandlet per sekund, linjer er antall kjerner.
Viser en korrelasjon av hvor godt Nginx behandler forespørsler etter hverandre. 8 kjerner gir bedre resultater i denne testen.
Denne grafen viser tydelig hvor mye bedre (ikke mye) Nginx fungerer på en enkelt kjerne. Hvis du har Nginx, bør du vurdere å redusere antall kjerner til én hvis du kun er vert for statiske.
IIS, selv om den har den laveste TTFB ifølge DevTools i Chrome, klarer å tape mot både Nginx og Apache i en seriøs kamp med stresstesten fra Apache Foundation.
All kurvatur på grafene er gjengitt jernbelagt.
En slags konklusjon:
Ja, Apache fungerer dårligere på 1 og 8 kjerner, men fungerer litt bedre på 4.
Ja, Nginx på 8 kjerner behandler forespørsler bedre etter hverandre, på 1 og 4 kjerner, og fungerer dårligere når det er mange tilkoblinger.
Ja, IIS foretrekker 4 kjerner for flertrådede arbeidsbelastninger og foretrekker 8 kjerner for enkelttrådede arbeidsbelastninger. Til syvende og sist var IIS litt raskere enn alle andre på 8 kjerner under høy belastning, selv om alle servere var på nivå.
Dette er ikke en målefeil, feilen her er ikke mer enn +-1ms. i forsinkelser og ikke mer enn +- 2-3 forespørsler per sekund for RPR.
Resultatene der 8 kjerner presterer dårligere er slett ikke overraskende, mange kjerner og SMT/Hyperthreading forringer ytelsen kraftig hvis vi har en tidsramme der vi må fullføre hele pipelinen.
Kilde: www.habr.com