Hem parlat de la metodologia a article, en aquest provem HTTPS, però en escenaris més realistes. Per a la prova, vam obtenir un certificat Let's Encrypt i vam habilitar la compressió de Brotli a 11.
Aquesta vegada intentarem reproduir l'escenari de desplegament d'un servidor en un VDS o com a màquina virtual en un host amb un processador estàndard. A tal efecte, es va fixar un límit en:
- 25% - El que equival a una freqüència de ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
El nombre de connexions puntuals s'ha reduït de 500 a 1, 3, 5, 7 i 9.
Resultats:
Retards:
TTFB es va incloure específicament com a prova independent, perquè HTTPD Tools crea un usuari nou per a cada sol·licitud individual. Aquesta prova encara està bastant deslligada de la realitat, perquè l'usuari encara farà clic a un parell de pàgines i, en realitat, TTFP jugarà el paper principal.
La primera, generalment la primera sol·licitud després del primer inici de la màquina virtual IIS, triga una mitjana de 120 ms.
Totes les sol·licituds posteriors mostren un TTFP d'1.5 ms. Apache i Nginx estan endarrerits en aquest sentit. Personalment, l'autor considera que aquesta prova és la més reveladora i triaria el guanyador només en funció d'ella.
El resultat no és sorprenent, ja que IIS guarda a la memòria cau el contingut estàtic ja comprimit i no el comprimeix cada vegada que s'hi accedeix.
Temps dedicat per client
Per avaluar el rendiment, n'hi ha prou amb una prova amb una única connexió.
Per exemple, IIS va completar una prova de 5000 usuaris en 40 segons, que són 123 sol·licituds per segon.
Els gràfics següents mostren el temps fins que el contingut del lloc es transfereix completament. Aquesta és la proporció de sol·licituds completades en un temps determinat. En el nostre cas, el 80% de totes les sol·licituds es van processar en 8 ms a IIS i en 4.5 ms a Apache i Nginx, i el 8% de totes les sol·licituds a Apache i Nginx es van completar en un interval de fins a 98 mil·lisegons.
Temps durant el qual es van processar 5000 sol·licituds:
Temps durant el qual es van processar 5000 sol·licituds:
Si teniu una màquina virtual amb una CPU de 3.5 GHz i 8 nuclis, trieu el que vulgueu. Tots els servidors web són molt semblants en aquesta prova. A continuació parlarem de quin servidor web triar per a cada amfitrió.
Quan es tracta d'una situació una mica més realista, tots els servidors web s'enfronten.
Rendiment:
Gràfic de retards en funció del nombre de connexions simultànies. Més suau i més baix és millor. L'últim 2% es va eliminar dels gràfics perquè els farien il·legibles.
Ara considerem l'opció on el servidor està allotjat a l'allotjament virtual. Prenem 4 nuclis a 2.2 GHz i un nucli a 1.8 GHz.
Com escalar
Si alguna vegada heu vist com són les característiques de tensió actual dels triodes al buit, pentodes, etc., aquests gràfics us seran familiars. Això és el que estem intentant captar: la saturació. El límit és quan no importa quants nuclis llanci, l'augment de rendiment no es notarà.
Abans, tot el repte era processar el 98% de les sol·licituds amb la latència més baixa per a totes les sol·licituds, mantenint la corba el més plana possible. Ara, construint una altra corba, trobarem el punt de funcionament òptim per a cadascun dels servidors.
Per fer-ho, prenem l'indicador Sol·licituds per segon (RPR). Horitzontal és la freqüència, vertical és el nombre de peticions processades per segon, les línies són el nombre de nuclis.
Mostra una correlació de com Nginx processa les sol·licituds una darrere l'altra. 8 nuclis funcionen millor en aquesta prova.
Aquest gràfic mostra clarament quant millor (no gaire) funciona Nginx en un sol nucli. Si teniu Nginx, hauríeu de considerar reduir el nombre de nuclis a un si només allotgeu els estàtics.
IIS, tot i que té el TTFB més baix segons DevTools a Chrome, aconsegueix perdre tant amb Nginx com amb Apache en una lluita seriosa amb la prova d'estrès de la Fundació Apache.
Tota la curvatura dels gràfics es reprodueix amb revestiment de ferro.
Una mena de conclusió:
Sí, Apache funciona pitjor en 1 i 8 nuclis, però funciona una mica millor en 4.
Sí, Nginx en 8 nuclis processa les peticions millor una darrere l'altra, en 1 i 4 nuclis, i funciona pitjor quan hi ha moltes connexions.
Sí, IIS prefereix 4 nuclis per a càrregues de treball multiprocés i prefereix 8 nuclis per a càrregues de treball d'un sol fil. En última instància, IIS era una mica més ràpid que tots els altres en 8 nuclis amb una càrrega elevada, tot i que tots els servidors estaven a la par.
Aquest no és un error de mesura, l'error aquí no és superior a +-1 ms. amb retards i no més de +- 2-3 sol·licituds per segon per a RPR.
Els resultats en què 8 nuclis funcionen pitjor no són gens sorprenents, molts nuclis i SMT/Hyperthreading degraden molt el rendiment si tenim un període de temps en el qual hem de completar tot el pipeline.
Font: www.habr.com
