Il tempo di risposta è un fattore cruciale nella gestione di un server web. Una configurazione non ottimale può pregiudicare le prestazioni del server, comportando un uso eccessivo delle risorse e compromettendo altri importanti fattori utili in ottica SEO (banda occupata, numero di connessioni richieste, latenza, ecc.).
Sebbene Nginx sia un server sufficientemente performante già con i parametri di configurazione di default, un'attenta revisione degli stessi è fondamentale per ottenere il meglio dal proprio server. In questa lezione elenchiamo alcuni degli aspetti da considerare per ottimizzare le prestazioni del server.
Utilizzare la direttiva sendfile
Quando il server Nginx è utilizzato per servire contenuti statici, il processo worker che gestisce la richiesta apre il file richiesto, ne carica il contenuto (parziale o totale) in memoria e poi trasmette il contenuto del buffer di memoria al client. Questa operazione è poco efficiente dato che richiede la creazione di una copia del file in memoria.
Un'alternativa possibile è data dall'utilizzo dell'API sendfile, disponibile sia in ambiente Linux che FreeBSD. L'API di sistema sendfile richiede al kernel di trasferire dei blocchi di dati tra due descrittori di file. Ricordiamo che in ambiente Unix tutto è essenzialmente un file, e pertanto la sendfile può essere utilizzata per inviare direttamente il contenuto di un file presente nel filesystem ad un client connesso al server semplicemente specificando come descrittore di destinazione quello della socket TCP relativa alla connessione con il client.
Per attivare questa ozpione è sufficiente impostare la direttiva sendfile su on nel blocco location. Inoltre, è possibile specificare la dimensione dei blocchi in cui suddividere il file da inviare, onde evitare la saturazione del processo worker nel caso di file di grandi dimensioni. Ciò è possibile con la direttiva sendfile_max_chunk. L'esempio seguente mostra come usarle entrambe:
# ...
location /videos {
sendfile on;
sendfile_max_chunk 1m;
#...
}
# ...Abilitare HTTP/2
L'introduzione del protocollo HTTP/2 ha rivoluzionato il mondo del web. Basato sul protocollo SPDY, nato in casa Google, e del quale mantiene buona parte delle caratteristiche, HTTP/2 è ormai supportato da quasi tutti i browser disponibili (ad eccezione di IE ed Opera mini).
I vantaggi introdotti da HTTP/2 sono numerosi, ma possono essere sintetizzati come segue:
- Tutte le richieste possono avvenire in parallelo invece che in sequenza;
- Anche gli header HTTP vengono compressi (con HPACK);
- Il protocollo è binario invece che testuale come HTTP. Ciò ottimizza l'utilizzo di banda (in generale i protocolli testuali sono più prolissi) e soprattutto il tempo di processing e di parsing lato client;
- HTTP/2 introduce i trasferimenti push: il server può inviare dati al client anche in assenza di una specifica richiesta;
Abilitare HTTP/2 in Nginx è piuttosto semplice: è sufficiente aggiungere la parola chiave http2 all'elenco dei protocolli indicati nella direttiva listen. Ad esempio:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
#...
}
# ...
Come si può notare nell'esempio precedente, la direttiva listen attiva anche SSL. Ciò è fondamentale poichè HTTP/2 richiede esplicitamente l'attivazione di TLS/SSL. Tuttavia, particolare attenzione va rivolta alla configurazione del modulo TLS/SSL, dato che alcuni cifrari sono deprecati in HTTP/2 per ragioni di sicurezza. Si consiglia pertanto di configurare la direttiva ssl_ciphers come segue:
# ...
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
# ...
Maggiori informazioni sull'uso della direttiva ssl_ciphers sono riportate nella lezione sulla configurazione di SSL.
Attivare la compressione
Comprimere i dati prima di trasmetterli al client consente di ridurre la banda occupata in trasmissione. Come è noto, il protocollo HTTP consente di utilizzare diversi algoritmi di compressione, tra i quali il famoso DEFLATE, implementato in gzip. Proprio quest'ultimo è stato recentemente al centro di una vulnerabilità di sicurezza, battezzata CRIME, che consente ad un attaccante di risalire ai dati in chiaro scambiati tra server e client sebbene la connessione sia protetta con TLS. Si sconsiglia pertanto di utilizzare gzip nel caso in cui si trasmettano dati riservati.
Per abilitare la compressione gzip è sufficiente impostare la direttiva gzip su on nel blocco server. Ad esempio:
server {
gzip on;
gzip_types text/plain application/xml;
gzip_min_length 1000;
#...
}
# ...
Con la direttiva gzip abilitata, i dati richiesti verranno compressi prima di essere trasmessi al client. La direttiva gzip_types permettere di restringere il campo di azione della compressione ai soli tipi MIME specificati.
Nell'esempio precedente, il server comprimerà solo file di testo o file XML. In generale, questa specifica è consigliata in modo da evitare di comprimere ulteriormente file già compressi con tecniche di compressione più efficienti. Ad esempio, comprimere con gzip un'immagine JPEG è un'operazione del tutto inutile.
Infine, la direttiva gzip_min_length disabilita la compressione per file la cui dimensione è inferiore al numero di bytes indicati. In riferimento all'esempio di prima, il server non comprimerà file di testo di dimensione inferiore ai 1000 byte.
Un altro aspetto da considerare prima di attivare la compressione gzip on the fly è il tempo di elaborazione addizionale richiesto per la compressione dei dati stessi. Se da una parte lo spazio occupato in trasmissione si riduce, e quindi con esso anche il tempo di trasferimento, l'operazione di compressione stessa richiede un certo tempo.
Per ovviare a questo problema, nel caso in cui si voglia utilizzare la compressione gzip per servire contenuti statici, è possibile abilitare la direttiva gzip_static:
location /xml {
gzip_static on;
#...
}
# ...Questa direttiva richiede al server di cercara nel file system una versione compressa del file. Ad esempio, richiedendo il file dati.xml, il server cercherà il file dati.xml.gz. Nel caso in cui il file sia presente nel file system, il server invierà il file .gz invece della versione non compressa. In questo caso, la compressione non viene effettuata da Nginx per ogni richiesta, ma va effettuata esternamente.
