Kiedy używać lub nie używać sendfile w Nginx?

Mamy to ustawienie już nginx.confod dłuższego czasu.

sendfile on;

Kiedy zaktualizujemy plik np. /js/main.jsI uzyskamy dostęp z przeglądarki https://test.com/js/main.js?newrandomtimestamp , nadal ładuje starszą wersję, chyba że wykonamy pełne odświeżenie (wyczyszczenie pamięci podręcznej) z naszej przeglądarki.

Ale kiedy zmienimy ustawienia z sendfile na; wysłać plik; przeglądarka załaduje poprawną wersję zaktualizowanego pliku.

Na naszym produkcyjnym serwerze internetowym powinniśmy używać sendfile; lub wyślij plik ;? Jeśli plik wysyłania jest włączony; jest wymagane (może z powodu lepszego buforowania? Szybsza wydajność?) niż jak rozwiązać wyżej wspomniany problem?

Poniżej znajduje się nginx.confnasz serwer produkcyjny i używamy wersji 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

— leśny klaun
źródło

Aby to ułatwić, czy powinniśmy restartować nginx za każdym razem, gdy wdrażamy nowe pliki na naszym serwerze produkcyjnym? Jeśli nie chcemy ponownie uruchamiać nginx, jak inaczej możemy wyczyścić pamięć podręczną nginx? (przy założeniu, że

— plik wysyłania

Czy twój Nginx w jakimś wirtualnym środowisku (np. Virtualbox)?

— Alexey Ten

Nasz serwer produkcyjny znajduje się na Amazon EC2

— forestclown

Istnieje kilka raportów o błędach sendfilei napędzie VirtualBox (np. Virtualbox.org/ticket/819 ). Być może istnieje podobny problem z Amazonem.

— Alexey Ten

Sprawdź ustawienia konfiguracji open_file_cache podczas uderzania w tę wewnętrzną pamięć podręczną tutaj. Możesz go całkowicie wyłączyć lub zmniejszyć TTL (open_file_cache_valid). Więcej informacji znajdziesz tutaj: nginx.org/en/docs/http/… Wspomniane problemy związane z Virtualbox są spowodowane specyficznym systemem plików VBOXSF, ale tutaj nie powinno tak być. Inne znane problemy są powiązane z systemem plików NFS, którego tutaj również nie ma.

— Jens Bradler,

Odpowiedzi:

Rozwiązanie problemu buforowania plików może być rozwiązane na poziomie aplikacji. Jest to dobrze znany problem w świecie programowania JavaScript. Rozwiązanie to zwykle nazywane jest „skrótem wyjściowym”.

Podstawowym pomysłem jest dodanie skrótu zawartości pliku do nazwy pliku, aby plik został uznany za „nowy” i nie został znaleziony w pamięci podręcznej.

Angular robi to w czasie kompilacji (patrz --outputHashing:).

— Anthony Mastrean
źródło

... chyba że zrobimy pełne odświeżenie (wyczyść pamięć podręczną) z naszej przeglądarki.

To samo w sobie jest wyraźnym przejawem, że „problem” występuje po stronie klienta.

sendfile nie ma nic wspólnego z buforowaniem, tylko sposób buforowania / odczytywania pliku przez NGINX (próba wpychania zawartości bezpośrednio do „gniazda” sieciowego lub najpierw buforowania jej zawartości).

Jedynym rozsądnym wyjaśnieniem jest to, że Twoja przeglądarka odrzuca ?newrandomtimestampjako parametr bez wartości, więc ładuje ten sam zasób buforowany dla jednego example.com?blahi drugiego example.com?boo.

Jeśli spróbujesz, to https://example.com/js/main.js?v=newrandomtimestampschemat powinien za każdym razem dawać nowszą treść.

— Danila Vershinin
źródło

csn używa również wykluczenia z buforowania tego pliku, tak jak ja

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

— djdomi
źródło