Over de methode hebben we eerder verteld in het artikel, waarin we HTTPS testen, maar in meer realistische scenario's. Voor de tests is een Let’s Encrypt-certificaat verkregen en is Brotli-compressie ingeschakeld op niveau 11.
Deze keer proberen we een scenario voor de uitrol van een server op VDS of als een virtuele machine op een host met een standaardprocessor na te bootsen. Hiervoor hebben we een limiet ingesteld van:
- 25% — wat overeenkomt met een frequentie van ~ 1350 MHz
- 35% - 1890 MHz
- 41% — 2214 MHz
- 65% — 3510 MHz
Het aantal gelijktijdige verbindingen is verminderd van 500 naar 1, 3, 5, 7 en 9,
Resultaten:
Vertragingen:
TTFB is speciaal als afzonderlijke test uitgevoerd, omdat HTTPD Tools voor elke afzonderlijke aanvraag als het ware een nieuwe gebruiker creëert. Deze test is nog steeds vrij losjes verbonden met de realiteit, want een gebruiker zal toch een paar pagina's klikken, en in werkelijkheid zal TTFP een belangrijke rol spelen.
De eerste, eigenlijk de allereerste aanvraag na de eerste start van de virtuele machine IIS, duurt gemiddeld 120 ms.
Alle volgende aanvragen tonen een TTFP van 1,5 ms. Apache en Nginx blijven hierin achter. De auteur beschouwt deze test als de meest indicatieve en zou de winnaar alleen op basis daarvan kiezen.
Het resultaat is niet verrassend, aangezien IIS al gecomprimeerde statische inhoud cacht en deze niet elke keer opnieuw comprimeert wanneer deze wordt opgevraagd.
Tijd besteed aan één klant
Voor een beoordeling van de prestaties is zelfs een test met 1 gelijktijdige verbinding voldoende.
Bijvoorbeeld, IIS voltooide de test met 5000 gebruikers in 40 seconden, wat 123 aanvragen per seconde betekent.
In de onderstaande grafieken is de tijd tot de volledige overdracht van de website-inhoud weergegeven. Dit is het percentage aanvragen dat in een bepaalde tijd is uitgevoerd. In ons geval werd 80% van alle aanvragen binnen 8 ms verwerkt op IIS en binnen 4,5 ms op Apache en Nginx, terwijl 98% van alle aanvragen binnen 8 milliseconden zijn uitgevoerd op Apache en Nginx.
De tijd die nodig was om 5000 aanvragen te verwerken:
De tijd die nodig was om 5000 aanvragen te verwerken:
Als je een virtuele machine hebt met een CPU van 3,5 GHz en 8 cores, kies dan wat je wilt. Alle webservers zijn erg vergelijkbaar in deze tests. Over welke webserver je voor elke host moet kiezen, zullen we later bespreken.
Wanneer we het over een iets realistischer scenario hebben, gaan alle webservers gelijk op.
Throughput:
Grafiek van vertragingen op basis van het aantal gelijktijdige verbindingen. Hoe vlakker en lager – hoe beter. De laatste 2% zijn uit de grafieken gehaald omdat ze ze onleesbaar zouden maken.
Laten we nu een scenario overwegen waarin de server op virtuele hosting staat. We nemen 4 cores van 2,2 GHz en één core van 1,8 GHz.
Hoe ze schalen
Als je ooit hebt gezien hoe de karakteristieken van elektronenbuizen, pentodes, enzovoort eruitzien, zullen deze grafieken je bekend voorkomen. Dit is wat we proberen te vangen – verzadiging. De limiet, waarbij het toevoegen van meer cores niet leidt tot merkbare prestatieverbeteringen.
Voorheen bestond de uitdaging erin om 98% van de verzoeken te verwerken met de laagste latentie voor alle verzoeken, en de curve zo vlak mogelijk te houden. Nu, door een andere curve te construeren, vinden we het optimale werkpunt voor elke server.
Hiervoor nemen we de metric Requests per second (RPR). Op de horizontale as de frequentie, op de verticale as – het aantal verzoeken dat per seconde wordt verwerkt, lijnen – aantal cores.
De correlatie wordt getoond hoe goed Nginx verzoeken één voor één verwerkt. 8 cores presteren beter in zulke tests.
In deze grafiek is goed te zien hoe Nginx (niet veel beter) presteert op één core. Als je Nginx gebruikt, is het de moeite waard om na te denken over het verminderen van het aantal cores naar één, als je alleen statische bestanden host.
IIS, hoewel het de laagste TTFB heeft volgens DevTools in Chrome, verliest het van zowel Nginx als Apache in een serieuze stress-test van de Apache Foundation.
De kromming van de grafieken wordt nauwkeurig weergegeven.
Een soort conclusie:
Ja, Apache presteert duidelijk slechter op 1 en 8 cores, maar op 4 cores is het iets beter.
Ja, Nginx verwerkt beter aanvragen één voor één op 8 cores, maar presteert slechter op 1 en 4 cores wanneer er veel verbindingen zijn.
Ja, IIS geeft de voorkeur aan 4 cores voor multithreaded belasting en 8 cores voor single-threaded. Uiteindelijk bleek IIS iets sneller te zijn dan de anderen op 8 cores onder hoge belasting, hoewel alle servers gelijkwaardig presteerden.
Dit is geen meetfout, de afwijking is niet meer dan +-1 ms. in vertragingen en niet meer dan +-2-3 verzoeken per seconde voor RPR.
De resultaten waarbij 8 cores slechter presteerden, zijn helemaal niet verrassend; veel cores en SMT/Hyperthreading verslechteren de prestaties sterk als we tijdslimieten hebben waarbinnen we de hele pipeline moeten beëindigen.
Bron: habr.com
