Abbiamo parlato della metodologia in articolo, in questo testiamo HTTPS, ma in scenari più realistici. Per il test è stato ottenuto un certificato Let's Encrypt, la compressione Brotli è stata abilitata alle 11.
Questa volta proveremo a riprodurre lo scenario di distribuzione di un server su un VDS o come macchina virtuale su un host con un processore standard. A tal fine è stato fissato un limite pari a:
- 25% - Che equivale a una frequenza di ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Il numero di connessioni singole è stato ridotto da 500 a 1, 3, 5, 7 e 9,
Risultati:
Ritardi:
TTFB è stato specificamente incluso come test separato, poiché HTTPD Tools crea un nuovo utente per ogni singola richiesta. Questo test è ancora abbastanza staccato dalla realtà, perché l'utente cliccherà comunque un paio di pagine, e nella realtà il TTFP giocherà il ruolo principale.
La prima, generalmente la primissima richiesta dopo il primo avvio della macchina virtuale IIS, dura in media 120 ms.
Tutte le richieste successive mostrano un TTFP di 1.5 ms. Apache e Nginx sono in ritardo in questo senso. Personalmente, l'autore considera questo test il più rivelatore e sceglierebbe il vincitore solo in base ad esso.
Il risultato non sorprende poiché IIS memorizza nella cache il contenuto statico già compresso e non lo comprime ogni volta che vi si accede.
Tempo impiegato per cliente
Per valutare le prestazioni è sufficiente un test con 1 connessione una tantum.
Ad esempio, IIS ha completato un test su 5000 utenti in 40 secondi, ovvero 123 richieste al secondo.
I grafici seguenti mostrano il tempo necessario al trasferimento completo dei contenuti del sito. Questa è la percentuale di richieste completate in un dato momento. Nel nostro caso, l'80% di tutte le richieste sono state elaborate in 8 ms su IIS e in 4.5 ms su Apache e Nginx, mentre il 8% di tutte le richieste su Apache e Nginx sono state completate entro un intervallo massimo di 98 millisecondi.
Tempo durante il quale sono state elaborate 5000 richieste:
Tempo durante il quale sono state elaborate 5000 richieste:
Se disponi di una macchina virtuale con CPU da 3.5 GHz e 8 core, scegli quello che desideri. Tutti i server web sono molto simili in questo test. Parleremo di quale server web scegliere per ciascun host di seguito.
Quando si tratta di una situazione leggermente più realistica, tutti i server web si scontrano.
Throughput:
Grafico dei ritardi rispetto al numero di connessioni simultanee. Più liscio e più basso è meglio. L'ultimo 2% è stato rimosso dalle classifiche perché le avrebbero rese illeggibili.
Consideriamo ora l'opzione in cui il server è ospitato su un hosting virtuale. Prendiamo 4 core a 2.2 GHz e un core a 1.8 GHz.
Come ridimensionare
Se hai mai visto come appaiono le caratteristiche corrente-tensione di triodi a vuoto, pentodi e così via, questi grafici ti saranno familiari. Questo è ciò che stiamo cercando di catturare: la saturazione. Il limite è quando, indipendentemente dal numero di core lanciati, l'aumento delle prestazioni non sarà evidente.
In precedenza, l’intera sfida consisteva nell’elaborare il 98% delle richieste con la latenza più bassa per tutte le richieste, mantenendo la curva quanto più piatta possibile. Ora, costruendo un'altra curva, troveremo il punto di funzionamento ottimale per ciascuno dei server.
Per fare ciò, prendiamo l’indicatore Richieste al secondo (RPR). Orizzontale è la frequenza, verticale è il numero di richieste elaborate al secondo, linee sono il numero di core.
Mostra una correlazione tra la capacità di Nginx di elaborare le richieste una dopo l'altra. 8 core hanno prestazioni migliori in questo test.
Questo grafico mostra chiaramente quanto meglio (non molto) Nginx funzioni su un singolo core. Se hai Nginx, dovresti considerare di ridurre il numero di core a uno se ospiti solo quelli statici.
IIS, sebbene abbia il TTFB più basso secondo DevTools in Chrome, riesce a perdere sia contro Nginx che contro Apache in una seria lotta con lo stress test della Apache Foundation.
Tutta la curvatura dei grafici è riprodotta in ferro.
Una sorta di conclusione:
Sì, Apache funziona peggio su 1 e 8 core, ma funziona un po' meglio su 4.
Sì, Nginx su 8 core elabora meglio le richieste uno dopo l'altro, su 1 e 4 core, e funziona peggio quando ci sono molte connessioni.
Sì, IIS preferisce 4 core per carichi di lavoro multi-thread e preferisce 8 core per carichi di lavoro a thread singolo. Alla fine, IIS è stato leggermente più veloce di tutti gli altri su 8 core sotto carico elevato, sebbene tutti i server fossero alla pari.
Questo non è un errore di misurazione, l'errore qui non è superiore a +-1ms. in ritardi e non più di +- 2-3 richieste al secondo per RPR.
I risultati in cui 8 core hanno prestazioni peggiori non sono affatto sorprendenti, molti core e SMT/Hyperthreading degradano notevolmente le prestazioni se abbiamo un intervallo di tempo in cui dobbiamo completare l'intera pipeline.
Fonte: habr.com