We spraken over de techniek in artikel testen we in dit artikel HTTPS, maar in meer realistische scenario's. Voor het testen hebben we een Let's Encrypt-certificaat verkregen en Brotli-compressie tot 11 ingeschakeld.
Deze keer zullen we proberen het scenario te reproduceren van het inzetten van een server op een VDS of als een virtuele machine op een host met een standaardprocessor. Hiervoor is een limiet vastgesteld op:
- 25% - Dit komt overeen met een frequentie van ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Het aantal eenmalige aansluitingen is teruggebracht van 500 naar 1, 3, 5, 7 en 9,
Resultaten:
Vertragingen:
TTFB is specifiek als aparte test meegenomen, omdat HTTPD Tools voor ieder individueel verzoek een nieuwe gebruiker aanmaakt. Deze test staat nog steeds vrij los van de werkelijkheid, omdat de gebruiker nog steeds op een paar pagina's zal klikken, en in werkelijkheid zal TTFP de hoofdrol spelen.
Het eerste, doorgaans het allereerste verzoek na de eerste start van de virtuele IIS-machine duurt gemiddeld 120 ms.
Alle daaropvolgende verzoeken tonen een TTFP van 1.5 ms. Apache en Nginx lopen wat dit betreft achter. Persoonlijk vindt de auteur deze test het meest onthullend en zou hij alleen op basis daarvan de winnaar kiezen.
Het resultaat is niet verrassend, aangezien IIS reeds gecomprimeerde statische inhoud in de cache opslaat en deze niet elke keer comprimeert wanneer deze wordt geopend.
Tijdsbesteding per klant
Om de prestaties te beoordelen is een test met 1 enkele aansluiting voldoende.
IIS voltooide bijvoorbeeld een test van 5000 gebruikers in 40 seconden, wat neerkomt op 123 verzoeken per seconde.
De onderstaande grafieken tonen de tijd totdat de site-inhoud volledig is overgedragen. Dit is het percentage verzoeken dat in een bepaalde tijd is voltooid. In ons geval werd 80% van alle verzoeken verwerkt in 8 ms op IIS en in 4.5 ms op Apache en Nginx, en werd 8% van alle verzoeken op Apache en Nginx voltooid binnen een interval van maximaal 98 milliseconden.
Tijd waarin 5000 verzoeken zijn verwerkt:
Tijd waarin 5000 verzoeken zijn verwerkt:
Als je een virtuele machine hebt met een 3.5 GHz CPU en 8 cores, kies dan wat je wilt. Alle webservers lijken in deze tests erg op elkaar. Hieronder bespreken we welke webserver we voor elke host moeten kiezen.
Als het om een iets realistischere situatie gaat, nemen alle webservers het tegen elkaar op.
Doorvoer:
Grafiek van vertragingen versus het aantal gelijktijdige verbindingen. Soepeler en lager is beter. De laatste 2% zijn uit de grafieken verwijderd omdat ze daardoor onleesbaar zouden worden.
Laten we nu eens kijken naar de optie waarbij de server wordt gehost op virtuele hosting. Laten we 4 cores nemen op 2.2 GHz en één core op 1.8 GHz.
Hoe te schalen
Als je ooit hebt gezien hoe de stroom-spanningskarakteristieken van vacuümtriodes, pentodes, enzovoort eruitzien, zullen deze grafieken je bekend voorkomen. Dit is wat we proberen te vangen: verzadiging. De limiet is dat, ongeacht hoeveel cores je gooit, de prestatieverbetering niet merkbaar zal zijn.
Voorheen was de hele uitdaging om 98% van de verzoeken met de laagste latentie voor alle verzoeken te verwerken, waarbij de curve zo vlak mogelijk bleef. Door nu een andere curve te construeren, zullen we het optimale werkpunt voor elk van de servers vinden.
Laten we hiervoor de indicator Requests per second (RPR) nemen. Horizontaal is de frequentie, verticaal is het aantal verwerkte verzoeken per seconde, lijnen zijn het aantal kernen.
Toont een correlatie van hoe goed Nginx verzoeken achter elkaar verwerkt. 8 kernen presteren beter in deze test.
Deze grafiek laat duidelijk zien hoeveel beter (niet veel) Nginx op een enkele kern werkt. Als je Nginx hebt, kun je overwegen om het aantal cores terug te brengen tot één als je alleen statische cores host.
IIS, hoewel het volgens DevTools in Chrome de laagste TTFB heeft, weet te verliezen van zowel Nginx als Apache in een serieus gevecht met de stresstest van de Apache Foundation.
Alle krommingen van de grafieken worden op ijzeren wijze weergegeven.
Een soort conclusie:
Ja, Apache werkt slechter op 1 en 8 cores, maar werkt iets beter op 4.
Ja, Nginx op 8 cores verwerkt verzoeken beter na elkaar, op 1 en 4 cores, en werkt slechter als er veel verbindingen zijn.
Ja, IIS geeft de voorkeur aan 4 kernen voor werkbelastingen met meerdere threads en geeft de voorkeur aan 8 kernen voor werkbelastingen met één thread. Uiteindelijk was IIS iets sneller dan alle anderen op 8 cores onder hoge belasting, hoewel alle servers op hetzelfde niveau waren.
Dit is geen meetfout, de fout bedraagt hier maximaal +-1ms. in vertragingen en niet meer dan +- 2-3 verzoeken per seconde voor RPR.
De resultaten waarbij 8 cores slechter presteren zijn helemaal niet verrassend; veel cores en SMT/Hyperthreading verminderen de prestaties aanzienlijk als we een tijdsbestek hebben waarin we de hele pijplijn moeten voltooien.
Bron: www.habr.com