Назад | Перейти на главную страницу

Когда использовать или не использовать sendfile on / off в Nginx?

У нас есть этот параметр в нашем nginx.conf некоторое время.

sendfile on;

Когда мы обновили файл, например /js/main.js и доступ из браузера https://test.com/js/main.js?newrandomtimestamp, он все равно загрузит старую версию, если мы не выполним полное обновление (очистку кеша) в нашем браузере.

Но когда мы меняем настройки из файла отправки; отправить файл; браузер загрузит правильную версию обновленного файла.

Следует ли использовать sendfile для нашего производственного веб-сервера; или отправить файл ;? Если sendfile включен; требуется (может по причине лучшего кеширования? более высокой производительности?), то как решить упомянутую выше проблему?

Ниже nginx.conf на нашем производственном сервере, и мы используем версию 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;
}

... если мы не выполняем полное обновление (очищаем кеш) в нашем браузере.

Это само по себе явное проявление того, что «проблема» находится на стороне клиента.

sendfile не имеет ничего общего с кешированием, только как NGINX буферизует / читает файл (пытается вставить содержимое непосредственно в сетевой «слот» или сначала буферизует его содержимое).

Единственное разумное объяснение заключается в том, что ваш конкретный браузер отклоняет ?newrandomtimestamp как параметр без значения, поэтому он загружает один и тот же кешированный ресурс для любого example.com?blah и example.com?boo.

Если вы попробуете, то https://example.com/js/main.js?v=newrandomtimestamp схема, должен давайте каждый раз новый контент.

Решение проблемы с кешированием файлов может быть найдено на уровне приложения. Это хорошо известный проблема в мире разработки JavaScript. Решение обычно называется «выходным хешированием».

Основная идея состоит в том, чтобы добавить хэш содержимого файла к имени файла, чтобы файл считался «новым» и не находился в кеше.

Angular делает это во время сборки (см.: --outputHashing).

вы также можете использовать исключение из кеширования этого файла, как я

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