¿Cuándo usar o no usar sendfile activado / desactivado en Nginx?

Tenemos esta configuración en nuestro nginx.confdurante bastante tiempo.

sendfile on;

Cuando hemos actualizado un archivo, por ejemplo, /js/main.jsy accedemos desde el navegador https://test.com/js/main.js?newrandomtimestamp , todavía cargará la versión anterior a menos que hagamos una actualización completa (borrar caché) desde nuestro navegador.

Pero cuando cambiamos la configuración de sendfile en adelante; enviar el archivo; el navegador cargará la versión correcta del archivo actualizado.

Para nuestro servidor web de producción, ¿deberíamos usar sendfile on; o enviar el archivo? Si se envía el archivo; se requiere (¿mayo debido a un mejor almacenamiento en caché? ¿Un rendimiento más rápido?) ¿Entonces cómo resolver el problema mencionado anteriormente?

A continuación se muestra nginx.confen nuestro servidor de producción, y estamos utilizando la versión 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

— payaso
fuente

Para facilitar las cosas, ¿deberíamos reiniciar nginx cada vez que implementamos nuevos archivos en nuestro servidor de producción? Si no queremos reiniciar nginx, ¿de qué otra manera podemos borrar el caché nginx? (suponiendo que el

— archivo de envío esté activado

¿Tu nginx en algún tipo de entorno virtual (como virtualbox)?

— Alexey Ten

Nuestro servidor de producción está en Amazon EC2

— forestclown

Hay varios informes de errores sendfiley una unidad VirtualBox (por ejemplo, virtualbox.org/ticket/819 ). Puede haber un problema similar con Amazon.

— Alexey Diez

Echa un vistazo a la configuración de open_file_cache mientras estás accediendo a este caché interno aquí. Puede deshabilitarlo por completo o reducir el TTL (open_file_cache_valid). Encontrará más detalles aquí: nginx.org/en/docs/http/… Los problemas mencionados vinculados con Virtualbox se deben al sistema de archivos específico VBOXSF, pero este no debería ser el caso aquí. Otros problemas conocidos están vinculados al sistema de archivos NFS, que tampoco está aquí.

— Jens Bradler

Respuestas:

Puede haber una solución a su problema de almacenamiento en caché de archivos a nivel de aplicación. Es un problema bien conocido en el mundo del desarrollo de JavaScript. La solución generalmente se llama algo así como "hashing de salida".

La idea básica es agregar un hash del contenido del archivo al nombre del archivo para que el archivo se considere "nuevo" y no se encuentre en la memoria caché.

Angular lo hace en tiempo de construcción (ver:) --outputHashing.

— Anthony Mastrean
fuente

... a menos que hagamos una actualización completa (borrar caché) desde nuestro navegador.

Esto en sí mismo, una clara manifestación de que el "problema" está del lado del cliente.

sendfile no tiene nada que ver con el almacenamiento en caché, solo cómo NGINX almacena / lee el archivo (tratando de rellenar el contenido directamente en la "ranura" de la red, o almacenar primero su contenido).

La única explicación razonable es que su navegador específico se descarta ?newrandomtimestampcomo un parámetro sin valor, por lo que está cargando el mismo recurso en caché para cualquiera example.com?blahy example.com?boo.

Si lo prueba, entonces el https://example.com/js/main.js?v=newrandomtimestampesquema debería ofrecer contenido más nuevo cada vez.

— Danila Vershinin
fuente

también puede usar una exclusión del almacenamiento en caché de este archivo como lo hago

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

— djdomi
fuente