Quando utilizzare o non utilizzare il file send on / off in Nginx?

Abbiamo questa impostazione nel nostro nginx.confper un po 'di tempo.

sendfile on;

Quando abbiamo aggiornato un file, ad esempio /js/main.jse l'accesso dal browser https://test.com/js/main.js?newrandomtimestamp , caricherà comunque la versione precedente a meno che non eseguiamo un aggiornamento completo (svuota cache) dal nostro browser.

Ma quando cambiamo le impostazioni da sendfile in poi; per inviare file; il browser caricherà la versione corretta del file aggiornato.

Per il nostro server Web di produzione, dovremmo usare sendfile su; o sendfile off ;? Se sendfile è attivo; è necessario (maggio per una migliore memorizzazione nella cache? Prestazioni più veloci?) Quindi come risolvere il problema sopra menzionato?

Di seguito è riportato il nginx.confnostro server di produzione e stiamo utilizzando la versione 1.7.5:

user  nginx;
worker_processes  2;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
worker_rlimit_nofile 51200;

events {
    use epoll;
    worker_connections  51200;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    client_max_body_size 8m;
    sendfile        on;
    keepalive_timeout  65;

    real_ip_header X-Forwarded-For;
    set_real_ip_from 0.0.0.0/0;
    large_client_header_buffers 4 32k;

    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_http_version 1.1;
    gzip_comp_level 2;
    gzip_types text/plain application/x-javascript application/javascript text/css application/xml application/json;
    gzip_vary on;


    include /etc/nginx/conf.d/*.conf;
}

nginx cache

— forestclown
fonte

Per semplificare le cose, dovremmo riavviare nginx ogni volta che abbiamo distribuito nuovi file sul nostro server di produzione? Se non vogliamo riavviare nginx, in quale altro modo possiamo cancellare la cache di nginx? (supponendo che sendfile sia attivo; è correlato alla cache)

— forestclown,

Il tuo nginx è in qualche tipo di ambiente virtuale (come virtualbox)?

— Alexey Ten,

Il nostro server di produzione è su Amazon EC2

— forestclown,

Esistono diverse segnalazioni di bug relative sendfileall'unità VirtualBox (ad esempio virtualbox.org/ticket/819 ). Potrebbe esserci un problema simile con Amazon.

— Alexey Ten,

Controlla le impostazioni di configurazione di open_file_cache mentre stai colpendo questa cache interna qui. È possibile disabilitarlo completamente o ridurre il TTL (open_file_cache_valid). Puoi trovare maggiori dettagli qui: nginx.org/it/docs/http/… I problemi menzionati collegati a Virtualbox sono dovuti al file system specifico VBOXSF, ma qui non dovrebbe essere il caso. Altri problemi noti sono collegati al filesystem NFS che qui non è presente.

— Jens Bradler,

Risposte:

Potrebbe esserci una soluzione al problema di memorizzazione nella cache dei file a livello di applicazione. È un problema ben noto nel mondo dello sviluppo JavaScript. La soluzione è generalmente chiamata "hashing di output".

L'idea di base è aggiungere un hash del contenuto del file al nome del file in modo che il file sia considerato "nuovo" e non trovato nella cache.

Angular lo fa al momento della compilazione (vedi:) --outputHashing.

— Anthony Mastrean
fonte

... a meno che non eseguiamo un aggiornamento completo (svuota cache) dal nostro browser.

Questo di per sé, una chiara manifestazione che il "problema" è sul lato client.

sendfile non ha nulla a che fare con la memorizzazione nella cache, solo il modo in cui NGINX esegue il buffering / legge il file (cercando di inserire il contenuto direttamente nello "slot" di rete, o di bufferizzare prima il suo contenuto).

L'unica spiegazione ragionevole è che il tuo browser specifico scarta ?newrandomtimestampcome parametro senza valore, quindi sta caricando la stessa risorsa memorizzata nella cache per entrambi example.com?blahe example.com?boo.

Se ci provi, allora https://example.com/js/main.js?v=newrandomtimestampschema, dovrebbe dare ogni volta nuovi contenuti.

— Danila Vershinin
fonte

puoi anche usare un'esclusione dalla memorizzazione nella cache di questo file come faccio io

 location updater/serversettings.xml {
        expires -1;
        add_header 'Cache-Control' 'no-store, no-cache, 
 must-revalidate, proxy-revalidate, max-age=0';
    }

— djdomi
fonte