When to use or not to use sendfile on/off in Nginx?

We have this setting in our nginx.conf for quite a while.

sendfile on;

When we have updated a file e.g. /js/main.js and access from browser https://test.com/js/main.js?newrandomtimestamp, it will still load the older version unless we do a full refresh (clear cache) from our browser.

But when we change the settings from sendfile on; to sendfile off; the browser will load the correct version of the updated file.

For our production web server, should we use sendfile on; or sendfile off;? If sendfile on; is required (May for the reason of better caching? Faster performance?) then how to solve the problem mentioned above?

Below is the nginx.conf in our production server, and we are using version 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;
}

Solution 1:

... unless we do a full refresh (clear cache) from our browser.

This in itself, a clear manifestation that the "problem" is on the client-side.

sendfile has nothing to do with caching, only how NGINX buffers / reads the file (trying to stuff the contents directly into the network "slot", or buffer its contents first).

The only reasonable explanation is that your specific browser discards ?newrandomtimestamp as a parameter without value, so it's loading the same cached resource for either example.com?blah and example.com?boo.

If you give it a try, then https://example.com/js/main.js?v=newrandomtimestamp scheme, should give newer content every time.

Solution 2:

There may be a solution to your file caching problem at the application level. It's a well-known problem in the JavaScript development world. The solution is usually called something like "output hashing".

The basic idea is to add a hash of the file contents to the file name so that the file is considered "new" and not found in the cache.

Angular does it at build time (see: --outputHashing).

Solution 3:

you csn also use a exclude from the caching this file as i do

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