La battaglia dei server WEB. Parte 1 – un HTTP distaccato dalla realtà:

In questo articolo ci cimenteremo nel reverse engineering, per così dire. Daremo un'occhiata sotto il cofano di ciascun server web, sfruttandoli in modi che nessuno avrebbe mai pensato di fare.

Questo test è come misurare un cavallo sferico nel vuoto, è solo un insieme di dati che abbiamo raccolto e ora non sappiamo cosa farne.

Metodologia

Per i test, utilizziamo Ubuntu 18.04 LTS come sistema operativo per Nginx e Apache, e Windows Server Core 2019 per IIS. Tutti i sistemi operativi hanno ricevuto gli ultimi aggiornamenti fino al 04.12.2019.

I test sono stati effettuati esclusivamente tramite HTTP. Su ciascun server web girava la stessa pagina, un template gratuito per Jekyll di Codrops. Collegamento. La compressione gzip era disabilitata su ogni server web.

Il test di capacità è stato condotto con Httpd-tools utilizzando i parametri:

ab -n 50000 -c 500 http://192.168.76.204:80/

È stato impostato un limite sui server pari al 10%, 5% e 1% del core su 8, 4 e 1 core. Il computer utilizzato come banco di prova era un 9900K@5400MHz, il che significa che il server con un limite del 10% ottiene circa 540MHz per core.

Il test TTFB è stato eseguito al primo avvio del server e misurato tramite DevTools; dopo aver ottenuto il risultato, il server veniva spento e ripristinato a un punto di controllo precedente, per escludere la comparsa di eventuali cache.

Tester e server web si trovavano sulla stessa macchina e sullo stesso switch virtuale.

Per valutare subito il sottosistema di archiviazione, sono stati presentati i risultati dei benchmark ATTO e CrystalDiskMark, per avere un'idea dei colli di bottiglia.

I dati sono stati estratti dalla macchina virtuale:

Risultati:

TTFB:

Il TTFB medio su IIS è il più basso, 0,5 ms, contro 1,4 ms per Apache e 4 ms per Nginx.

Throughput:

Iniziamo a vedere quanto bene si scalano i vari server in base al numero di core.

Nel grafico è rappresentato il numero di richieste dal tester al server web e la latenza. Si può notare che NGINX ha gestito il 98% di tutte le richieste, restituendo il sito in 20 ms o meno. IIS e Apache hanno gestito l'ultimo 5% delle richieste in 76 ms e 14 ms rispettivamente.

Il grafico mostra il tempo medio di elaborazione di una richiesta durante il test di stress.

Come si può osservare dai grafici, IIS è risultato inferiore sia ad Apache che a Nginx, rallentando notevolmente sotto carico elevato. 

IIS ha chiaramente preferito 4 core rispetto a 8, mostrando minori latenze su quattro core, ma non ha mostrato un grande comportamento nemmeno su un solo core.

NGINX si scala perfettamente su tutti e 8 i core, mentre per Apache sembrerebbe che uno scenario a core singolo sia la scelta migliore.

Scalabilità:

Nginx:

Ora consideriamo la scalabilità in base alla frequenza e al numero di core. 

Nei test con un limite dell'1% su 4 e 1 core, Nginx non ha superato i 2000 richieste, interrompendo la connessione con il tester.

Apache:

Analogamente a Nginx, Apache ha gestito 2500 richieste ma ha poi ceduto, interrompendo la connessione. Apache non ha superato il test su 8, 4 e 1 core con un limite dell'1%, ma non ha nemmeno superato il test con un limite del 5% su un solo core, che è peggio rispetto a Nginx.

IIS:

Durante i test, IIS ha accumulato una grande coda di richieste, ma ha elaborato ciascuna di esse. Sembrerebbe che di default non abbia timeout per l'elaborazione delle richieste.

Nel diagramma è rappresentato il tempo impiegato per completare il test. Sono state escluse configurazioni di test completamente assurde. Dal diagramma risulta quanto IIS sia esigente in termini di hardware e quanto sia straordinario NGINX.

Scalabilità del disco:

Nginx:

Ora consideriamo 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 che aveva fallito 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 ciascuno di loro ha cachato la staticità nella RAM e lo ha restituito da lì. Qui vediamo il principale collo di bottiglia: il server web stesso.

È troppo presto per trarre conclusioni su questo 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