Vi pratade om tekniken artikel, i den här testar vi HTTPS, men i mer realistiska scenarier. För att testa fick vi ett Let's Encrypt-certifikat och aktiverade Brotli-komprimering till 11.
Den här gången ska vi försöka återskapa scenariot med att distribuera en server på en VDS eller som en virtuell maskin på en värd med en standardprocessor. För detta ändamål sattes en gräns till:
- 25% - Vilket motsvarar en frekvens på ~ 1350 MHz
- 35 % -1890 MHz
- 41 % - 2214 MHz
- 65 % - 3510 MHz
Antalet engångsanslutningar har minskat från 500 till 1, 3, 5, 7 och 9,
resultat:
Förseningar:
TTFB inkluderades specifikt som ett separat test, eftersom HTTPD Tools skapar en ny användare för varje enskild begäran. Detta test är fortfarande ganska fristående från verkligheten, eftersom användaren fortfarande klickar ett par sidor, och i verkligheten kommer TTFP att spela huvudrollen.
Den första, vanligtvis den allra första begäran efter den första starten av den virtuella IIS-maskinen, tar i genomsnitt 120 ms.
Alla efterföljande förfrågningar visar en TTFP på 1.5 ms. Apache och Nginx ligger efter i detta avseende. Personligen anser författaren detta test som det mest avslöjande och skulle bara välja vinnaren baserat på det.
Resultatet är inte förvånande eftersom IIS cachar redan komprimerat statiskt innehåll och inte komprimerar det varje gång det nås.
Tidsåtgång per kund
För att utvärdera prestanda räcker det med ett test med 1 enkel anslutning.
Till exempel genomförde IIS ett test av 5000 användare på 40 sekunder, vilket är 123 förfrågningar per sekund.
Graferna nedan visar tiden tills webbplatsens innehåll är helt överfört. Detta är andelen förfrågningar som fullföljs under en given tid. I vårt fall behandlades 80 % av alla förfrågningar på 8 ms på IIS och i 4.5 ms på Apache och Nginx, och 8 % av alla förfrågningar på Apache och Nginx slutfördes inom ett intervall på upp till 98 millisekunder.
Tid under vilken 5000 förfrågningar behandlades:
Tid under vilken 5000 förfrågningar behandlades:
Om du har en virtuell maskin med en 3.5 GHz CPU och 8 kärnor, välj sedan vad du vill ha. Alla webbservrar är väldigt lika i detta test. Vi kommer att prata om vilken webbserver du ska välja för varje värd nedan.
När det kommer till en lite mer realistisk situation går alla webbservrar varandra.
genomströmning:
Diagram över fördröjningar kontra antalet samtidiga anslutningar. Jämnare och lägre är bättre. De sista 2% togs bort från diagrammen eftersom de skulle göra dem oläsliga.
Låt oss nu överväga alternativet där servern är värd för virtuell värd. Låt oss ta fyra kärnor på 4 GHz och en kärna på 2.2 GHz.
Hur man skalar
Om du någonsin har sett hur strömspänningsegenskaperna hos vakuumtrioder, pentoder och så vidare ser ut, kommer dessa grafer att vara bekanta för dig. Det här är vad vi försöker fånga - mättnad. Gränsen är när, oavsett hur många kärnor du kastar, prestandaökningen inte kommer att märkas.
Tidigare var hela utmaningen att behandla 98 % av förfrågningarna med lägsta latens för alla förfrågningar, och hålla kurvan så platt som möjligt. Nu, genom att konstruera en annan kurva, kommer vi att hitta den optimala driftpunkten för var och en av servrarna.
För att göra detta, låt oss ta indikatorn Requests per second (RPR). Horisontell är frekvensen, vertikal är antalet förfrågningar som behandlas per sekund, linjer är antalet kärnor.
Visar en korrelation av hur väl Nginx bearbetar förfrågningar en efter en. 8 kärnor presterar bättre i detta test.
Denna graf visar tydligt hur mycket bättre (inte mycket) Nginx fungerar på en enda kärna. Om du har Nginx bör du överväga att minska antalet kärnor till en om du bara är värd för statiska.
IIS, även om det har lägst TTFB enligt DevTools i Chrome, lyckas förlora mot både Nginx och Apache i en allvarlig kamp med stresstestet från Apache Foundation.
All kurvatur i graferna är återgiven järnklädd.
Någon slags slutsats:
Ja, Apache fungerar sämre på 1 och 8 kärnor, men fungerar lite bättre på 4.
Ja, Nginx på 8 kärnor bearbetar förfrågningar bättre en efter en, på 1 och 4 kärnor, och fungerar sämre när det finns många anslutningar.
Ja, IIS föredrar 4 kärnor för flertrådiga arbetsbelastningar och föredrar 8 kärnor för enkeltrådade arbetsbelastningar. I slutändan var IIS något snabbare än alla andra på 8 kärnor under hög belastning, även om alla servrar var i nivå.
Detta är inte ett mätfel, felet här är inte mer än +-1ms. i förseningar och inte mer än +- 2-3 förfrågningar per sekund för RPR.
Resultaten av 8 kärnor som presterar sämre är inte alls förvånande, många kärnor och SMT/Hyperthreading försämrar prestanda kraftigt om vi har en tidsram inom vilken vi måste slutföra hela pipelinen.
Källa: will.com