Abbiamo discusso della metodologia in un articolo, in questo testiamo HTTPS, ma in scenari più realistici. È stato ottenuto un certificato Let’s Encrypt e la compressione Brotli è stata attivata al 11.
Questa volta proveremo a riprodurre uno scenario di distribuzione del server su VDS o come macchina virtuale su un host con un processore standard. Per questo sono stati impostati i limiti a:
- 25% — Che corrisponde a una frequenza di ~ 1350MHz
- 35% -1890MHz
- 41% — 2214MHz
- 65% — 3510MHz
Il numero di connessioni simultanee è stato ridotto da 500 a 1, 3, 5, 7 e 9,
Risultati:
Ritardi:
TTFB è stato appositamente isolato come test a parte, poiché HTTPD Tools crea come se fosse un nuovo utente per ogni richiesta separata. Questo test è ancora piuttosto distaccato dalla realtà, perché un paio di pagine l'utente potrebbe comunque cliccare, e in realtà il TTFP giocherà un ruolo principale.
La prima, in assoluto la prima richiesta dopo il primo avvio della macchina virtuale IIS viene gestita in media in 120 ms.
Tutte le successive richieste mostrano un TTFP di 1.5 ms. Apache e Nginx sono indietro in questo. Personalmente l'autore considera questo test il più significativo e sceglierebbe il vincitore solo in base a questo.
Il risultato non è sorprendente, poiché IIS memorizza nella cache il contenuto statico già compresso e non lo ricompone ogni volta che viene richiesto.
Tempo speso per un cliente
Per valutare le prestazioni, è sufficiente anche un test con 1 connessione simultanea.
Ad esempio, IIS ha completato il test di una lunghezza di 5000 utenti in 40 secondi, che corrisponde a 123 richieste al secondo.
Nei grafici sottostanti è riportato il tempo fino alla piena trasmissione del contenuto del sito. Questa è la frazione delle richieste completate in un certo tempo. Nel nostro caso, l'80% di tutte le richieste è stato elaborato in 8 ms su IIS e in 4.5 ms su Apache e Nginx, mentre il intervallo fino a 8 millisecondi ha visto il 98% di tutte le richieste elaborato su Apache e Nginx.
Tempo necessario per elaborare 5000 richieste:
Tempo necessario per elaborare 5000 richieste:
Se hai una macchina virtuale con un CPU da 3.5GHz e 8 core, scegli ciò che desideri. Tutti i server web sono molto simili in questo test. Di quale server web scegliere per ogni host parleremo a breve.
Quando si tratta di una situazione leggermente più reale, tutti i server web si sfidano testa a testa.
Throughput:
Grafico dei ritardi in funzione del numero di connessioni simultanee. Più è dritto e basso – meglio è. Gli ultimi 2% sono stati esclusi dai grafici perché li renderebbero illeggibili.
Ora consideriamo il caso in cui il server è ospitato su un hosting virtuale. Prendiamo 4 core a 2.2 GHz e un core a 1.8 GHz.
Come si scalano
Se hai mai visto come sono le curve caratteristiche dei triodi, pentodi e simili, questi grafici ti saranno familiari. Questo è esattamente ciò che stiamo cercando di catturare – saturazione. Il limite oltre il quale, indipendentemente da quanti core usi, l'aumento delle prestazioni non sarà evidente.
In precedenza, la sfida consisteva nell'elaborare il 98% delle richieste con la minore latenza possibile a fronte di tutte le richieste, mantenendo la curva il più uniforme possibile. Ora, costruendo un'altra curva, troveremo il punto di lavoro ottimale per ciascuno dei server.
Per questo utilizzeremo il parametro Requests per second (RPR). Sull'asse orizzontale la frequenza, sull'asse verticale – il numero di richieste elaborate al secondo, e le linee – il numero di core.
Mostra la correlazione di quanto bene Nginx elabora le richieste una dopo l'altra. 8 core in questo test si comportano meglio.
In questo grafico è chiaramente visibile quanto meglio (non di molto) funzioni Nginx su un singolo core. Se hai Nginx, vale la pena considerare di ridurre il numero di core a uno, se ospiti solo file statici.
Sebbene IIS abbia il TTFB più basso secondo DevTools in Chrome, riesce comunque a perdere contro Nginx e Apache in una seria battaglia contro il test di stress dell'Apache Foundation.
Tutta la curvatura dei grafici è riprodotta con precisione.
Una sorta di conclusione:
Sì, Apache funziona di fatto peggio su 1 e 8 core, mentre su 4 funziona leggermente meglio.
Sì, Nginx su 8 core gestisce meglio le richieste una dopo l'altra, mentre su 1 e 4 core funziona peggio quando ci sono molte connessioni.
Sì, IIS preferisce 4 core per carichi multithread e preferisce 8 core per carichi a thread singolo. Alla fine, IIS si è rivelato leggermente più veloce di tutti su 8 core sotto elevato carico, anche se tutti i server erano in pari.
Non si tratta di un errore di misurazione, l'errore non supera i +-1 ms nei ritardi e non più di +-2-3 richieste al secondo per il RPR.
I risultati in cui 8 core si comportano peggio non sono affatto sorprendenti; molti core e SMT/Hyperthreading peggiorano notevolmente le prestazioni se abbiamo delle scadenze entro le quali dobbiamo completare l’intero pipeline.
Fonte: habr.com
