Abbiamo parlato del metodo in un articolo, in questo testiamo HTTPS, ma in scenari più realistici. È stato ottenuto un certificato Let’s Encrypt e abilitata la compressione Brotli al 11%.
Questa volta proveremo a riprodurre uno scenario di distribuzione del server su un VDS o come macchina virtuale su un host con un processore standard. Per questo abbiamo impostato il limite 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:
Il TTFB è stato appositamente estratto come test separato, perché HTTPD Tools crea un nuovo utente per ogni singola richiesta. Questo test è ancora abbastanza distaccato dalla realtà, perché un utente cliccherà comunque su un paio di pagine, e nella realtà il TTFP giocherà il ruolo principale.
La prima, in assoluto la prima richiesta dopo il primo avvio della macchina virtuale IIS impiega in media 120 ms.
Tutte le richieste successive mostrano un TTFP di 1,5 ms. Apache e Nginx sono indietro in questo.
Personalmente, l'autore considera questo test il più rappresentativo e sceglierei il vincitore solo in base a questo.
Il risultato non è sorprendente, poiché IIS memorizza nella cache il contenuto statico compresso e non lo ricompresse ogni volta che viene richiesto.
Tempo speso per un cliente
Per valutare le prestazioni è sufficiente un test con una connessione simultanea.
Ad esempio, IIS ha completato il test con 5000 utenti in 40 secondi, ovvero 123 richieste al secondo.
Nei grafici sottostanti è riportato il tempo fino al completamento della trasmissione del contenuto del sito. Questa è la percentuale di richieste eseguite in un determinato intervallo di 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 l'intervallo fino a 8 millisecondi ha visto il 98% di tutte le richieste elaborate su Apache e Nginx.
Nei grafici sottostanti è riportato il tempo fino al completamento della trasmissione del contenuto del sito. Questa è la percentuale di richieste eseguite in un determinato intervallo di 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 l'intervallo fino a 8 millisecondi ha visto il 98% di tutte le richieste elaborate su Apache e Nginx.
Tempo impiegato per elaborare 5000 richieste:
Se hai una macchina virtuale con un CPU da 3,5GHz e 8 core, scegli quello che preferisci. Tutti i server web sono molto simili in questo test.
Throughput:
Quando si tratta di una situazione leggermente più realistica, tutti i server web si sfidano testa a testa.
Grafico dei ritardi in funzione del numero di connessioni simultanee. Più è piatto 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,2GHz e un core a 1,8GHz.
Come si scalano
Se hai mai visto come appaiono le curve di carico per triode, pentodi e simili, questi grafici ti assomiglieranno. È proprio questo che stiamo cercando di catturare – la saturazione. Il limite, quando non importa quanti core hai, l'aumento delle prestazioni non sarà percepito.
In precedenza, tutta la sfida consisteva nel gestire il 98% delle richieste con la latenza più bassa possibile, mantenendo la curva il più uniforme possibile. Ora, tracciando un'altra curva, troveremo il punto di lavoro ottimale per ciascun server.
Per questo prenderemo in considerazione il valore Requests per second (RPR). Sull'asse orizzontale la frequenza, sull'asse verticale — il numero di richieste elaborate al secondo, le linee – il numero di core.
Mostra la correlazione di quanto bene Nginx gestisce le richieste una dopo l'altra. 8 core in questo test sono più efficaci.
In questo grafico è chiaramente visibile quanto meglio (non di molto) Nginx funzioni su un singolo core. Se hai Nginx, dovresti considerare di ridurre il numero di core a uno, se ospiti solo contenuti statici.
Sebbene IIS abbia il TTFB più basso secondo DevTools in Chrome, riesce a perdere contro Nginx e Apache in una seria sfida con il test di stress di Apache Foundation.
Tutta la curvatura dei grafici è rappresentata in modo rigoroso.
In una sorta di conclusione:
Sì, Apache funziona decisamente 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 il carico multi-thread e preferisce 8 core per il carico single-thread. In definitiva, IIS si è rivelato leggermente più veloce di tutti su 8 core sotto carico elevato, anche se tutti i server si sono comportati in modo simile.
Non si tratta di un errore di misurazione; l'errore qui non supera ±1 ms nei ritardi e non più di ±2-3 richieste al secondo per l'RPR.
Fonte: habr.com
