In questo articolo proveremo a cimentarci nel reverse engineering, si può dire. Daremo uno sguardo con le nostre mani sporche sotto il cofano di ciascuno dei server web, sfruttandoli come nessuno avrebbe mai fatto.
Questo test è una misura di un cavallo sferico nel vuoto, non più di dati che sono stati raccolti e ora non sappiamo cosa farne.
Metodologia
Come sistema operativo per Nginx e Apache utilizziamo Ubuntu 18.04 LTS, per IIS Windows Server Core 2019. Tutti i sistemi operativi hanno ricevuto gli ultimi aggiornamenti alla data del 04.12.2019.
I test sono stati effettuati esclusivamente tramite HTTP. Su ciascuno dei server web girava la stessa pagina, un template gratuito per Jekyll di Codrops. . Su ciascuno dei server web è stata disattivata la compressione gzip.
Il test di throughput è stato eseguito con Httpd-tools con gli argomenti:
ab -n 50000 -c 500 http://192.168.76.204:80/Ai server è stato imposto un limite del 10, 5 e 1 percento del core su 8, 4 e un core. Il banco di prova era un computer con 9900K@5400MHz, il che significa che il server con un limite del 10% riceve circa 540MHz per core.
Il test TTFB è stato eseguito al primo avvio del server ed è stato misurato tramite DevTools; dopo aver ricevuto il risultato, il server è stato spento e riportato al precedente checkpoint per escludere l'emergere 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 di archiviazione, i risultati del benchmark ATTO e CrystalDiskMark, per avere un'idea delle strozzature.
I dati sono stati prelevati da una macchina virtuale:
Risultati:
TTFB:
Il TTFB medio su IIS è inferiore a tutti, 0,5ms, contro 1,4ms per Apache e 4ms per Nginx.
Throughput:
Iniziamo a esaminare quanto bene ciascun server scala in base al numero di core.
Nel grafico è rappresentato il numero di richieste del tester al server web e la latenza. Si può notare che NGINX ha gestito il 98% di tutte le richieste, restituendo il sito in 20ms o meno. IIS e Apache hanno impiegato gli ultimi 5% di tutte le richieste in 76ms e 14ms rispettivamente.
Nel grafico è mostrato il tempo medio di elaborazione di una singola richiesta durante il test di stress.
Come si può notare dai grafici, IIS ha avuto una prestazione inferiore sia rispetto ad Apache che a Nginx, rallentando considerevolmente sotto carichi elevati.
IIS ha chiaramente preferito 4 core rispetto a otto, mostrando minori latenze su quattro, ma non ha apprezzato molto nemmeno un singolo core.
NGINX si scalda splendidamente su tutti e 8 i core, mentre per Apache, a quanto sembra, uno scenario a core singolo sembra la scelta migliore.
Scalabilità:
Nginx:
Ora vediamo la scalabilità in base alla frequenza e al numero di core.
I test con un limite dell'1% su 4 e 1 core Nginx non hanno passato, interrompendo la connessione con il tester oltre i 2000 richieste.
Apache:
Anche Apache, come Nginx, dopo aver elaborato 2500 richieste ha ceduto e ha interrotto la connessione. Apache non ha superato il test su 8, 4 e 1 core con un limite dell'1%, e oltre a ciò non ha superato nemmeno il test con un limite del 5% su un core, il che è peggio di Nginx.
IIS:
IIS durante i test ha accumulato una fila gigantesca di richieste ma le ha elaborate tutte. A quanto pare, non ha timeout preimpostati per l'elaborazione delle richieste.
Il grafico mostra il tempo impiegato per completare il test. Sono state scartate configurazioni di test del tutto assurde. Dal grafico si vede quanto IIS sia esigente in termini di hardware e quanto sia straordinario NGINX.
Scalabilità dal disco:
Nginx:
Ora esaminiamo la scalabilità in base alla frequenza, al numero di core e alla velocità del disco.
Questa volta Nginx non ha superato 4 test invece di due.
Apache:
Apache ha fallito lo stesso numero di test, come la volta precedente.
IIS:
IIS mostra un grafico quasi identico, come se non ci fossero limitazioni sul disco. In generale, i grafici di tutti i server non sono cambiati molto, il che significa che ognuno di essi ha memorizzato la staticità in memoria e l'ha servita da lì. Qui vediamo il principale collo di bottiglia: il server web stesso.
È presto per trarre conclusioni basate su questo test, non abbiamo ancora testato HTTPS, compressione e HTTP/2 con un certificato attivo di Let’s Encrypt. Di questo parleremo nel prossimo articolo.
Fonte: habr.com
