In questo articolo ci proveremo con il reverse engineering, si potrebbe dire. Metteremo le mani sporche sotto il cofano di ogni server web, sfruttandoli in modi che nessuno sfrutterebbe mai.
Questo test è la misurazione di un cavallo sferico nel vuoto, nient'altro che i dati ottenuti e ora non sappiamo cosa farne.
tecnica
Il sistema operativo per Nginx e Apache è Ubuntu 18.04 LTS, per IIS Windows Server Core 2019. Prima dei test, tutti i sistemi operativi hanno ricevuto gli ultimi aggiornamenti a partire dal 04.12.2019 dicembre XNUMX.
I test sono stati eseguiti esclusivamente tramite HTTP. Ogni server web eseguiva la stessa pagina, un modello Jekyll gratuito di Codrops. . Ogni server web aveva la compressione gzip disabilitata.
Il test di throughput è stato eseguito con gli strumenti Httpd con gli argomenti:
ab -n 50000 -c 500 http://192.168.76.204:80/I server erano limitati al 10, 5 e 1% dei core su 8, 4 e un core. Il banco di prova era un computer con 9900K@5400MHz, il che significa che il server che riceve un limite del 10% riceve circa 540MHz per core.
Il test TTFB è stato eseguito al primo avvio del server e misurato utilizzando DevTools; dopo aver ricevuto il risultato, il server è stato spento ed è stato eseguito il rollback al checkpoint precedente per eliminare la comparsa di qualsiasi tipo di cache.
Il tester e il server web si trovavano sullo stesso host e sullo stesso switch virtuale.
Per valutare subito il sottosistema disco, i risultati dei benchmark ATTO e CrystalDIskMark in modo da avere un'idea dei colli di bottiglia.
Dati presi dalla macchina virtuale:
Risultati:
TTFB:
Il TTFB medio per IIS è il più piccolo, 0,5 ms, contro 1,4 ms per Apache e 4 ms per Nginx.
Throughput:
Per prima cosa, diamo un'occhiata alla scalabilità di ciascun server in base al numero di core.
Il grafico mostra il numero di chiamate del tester al server web e la latenza. Il grafico mostra che NGINX ha elaborato il 98% di tutte le richieste, consegnando il sito in 20 ms o meno. IIS, come Apache, ha completato l'ultimo 5% di tutte le chiamate rispettivamente in 76 ms e 14 ms.
Il grafico mostra il tempo medio di elaborazione per una richiesta durante uno stress test.
Come puoi vedere dai grafici, IIS ha spazzato via sia Apache che Nginx, rallentando notevolmente sotto carico elevato.
IIS preferiva chiaramente 4 core rispetto a XNUMX, mostrando latenze inferiori su XNUMX, ma non favoriva fortemente un core.
NGINX si adatta bene a tutti gli 8 core e per Apache lo scenario single-core sembra essere la scelta migliore.
Scalabilità:
nginx:
Consideriamo ora la scalabilità in termini di frequenza e numero di core.
Nginx non ha superato i test con limite dell'1% per 4 e 1 core; quando ha superato le 2000 richieste ha interrotto la connessione con il tester.
Apache:
Apache, come Nginx, dopo aver elaborato 2500 richieste, ha rinunciato e ha chiuso la connessione. Apache non ha superato il test su 8, 4 e 1 core con un limite dell'1%, ma in più ha fallito anche il test con un limite del 5% su un core, il che è peggio di Nginx
IIS:
Durante i test, IIS ha accumulato una gigantesca coda di richieste ma le ha elaborate ciascuna. Apparentemente, non sono previsti timeout impostati per l'elaborazione delle richieste.
Il grafico mostra il tempo impiegato per completare il test. Sono state scartate configurazioni di test completamente assurde. Il diagramma mostra quanto sia impegnativo IIS in termini di hardware e quanto sia meraviglioso NGINX.
Scalabilità da disco:
nginx:
Consideriamo ora la scalabilità in termini di frequenza, numero di core e velocità del disco.
Questa volta Nginx ha fallito 4 test invece di due.
Apache:
Apache ha fallito lo stesso numero di test dell'ultima volta.
IIS:
IIS mostra un grafico quasi identico, come se non ci fossero restrizioni sul disco. In generale, la grafica di tutti i server non è cambiata molto, il che significa che ciascuno di essi ha memorizzato nella cache i dati statici nella RAM e li ha serviti da lì. Qui vediamo il collo di bottiglia principale: il server web stesso.
È troppo presto per trarre conclusioni basate su questi test; non abbiamo ancora testato HTTPS, compressione e HTTP/2 con un certificato live di Let's Encrypt. Di questo parleremo nel prossimo articolo.
Fonte: habr.com