Erros de cache Nginx de depuração: Atingindo um alto número de MISS apesar do alto proxy válido

Question

Meu caminho do cache de proxy está definido para um tamanho muito alto

proxy_cache_path  /var/lib/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=700m;

e o tamanho usado é somente

sudo du -sh *
14M cache
4.0K    proxy

O cache de proxy válido está definido como

proxy_cache_valid 200 120d;

Eu rastreio HIT e MISS via

add_header X-Cache-Status $upstream_cache_status;

Apesar dessas configurações, estou vendo muitas MISSES. E isso é para páginas que eu intencionalmente executei um cache mais quente uma hora atrás.

Como eu depuro porque estas MISSes estão acontecendo? Como faço para descobrir se a falha ocorreu devido a despejo, expiração, algum cabeçalho nocivo etc? O Nginx fornece comandos para isso?

Editar : configuração completa

    # at http level
    proxy_cache_path  /var/lib/nginx/cache  levels=1:2 inactive=400d keys_zone=staticfilecache:180m  max_size=700m;
    proxy_temp_path /var/lib/nginx/proxy;
    proxy_connect_timeout 30;
    proxy_read_timeout 120;
    proxy_send_timeout 120;
    #prevent header too large errors
    proxy_buffers 256 16k;
    proxy_buffer_size 32k;
    #httpoxy exploit protection
    proxy_set_header Proxy "";

    # at server level 
    add_header Cache-BYPASS-Reason $skip_reason;

    # define nginx variables
    set $do_not_cache 0;
    set $skip_reason "";
    set $bypass 0;

    # security for bypass so localhost can empty cache
    if ($remote_addr ~ "^(127.0.0.1|Web.Server.IP)$") {
        set $bypass $http_8X0;
    }

    # skip caching WordPress cookies
    if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
        set $do_not_cache 1;
        set $skip_reason Cookie;
    }

    # Don't cache URIs containing the following segments
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php") {
        set $skip_cache 1;
        set $skip_reason URI;
    }

    # https://guides.wp-bullet.com/how-to-configure-nginx-reverse-proxy-wordpress-cache-apache/
    location / {
            proxy_pass http://127.0.0.1:8000;

            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Port 443;
            proxy_set_header Host $host;
            proxy_set_header Accept-Encoding "";

            # may need to comment out proxy_redirect if get login redirect loop
            proxy_redirect off;

            proxy_cache_key "$scheme://$host$uri";
            add_header X-Nginx-Cache-Head "$scheme://$host$uri";
            proxy_cache staticfilecache;
            proxy_cache_valid       200 301 302 100d;
            proxy_cache_valid 404 1m;


            add_header Cache-Control public;

            proxy_ignore_headers Expires;
            proxy_ignore_headers  "Cache-Control";
            proxy_ignore_headers X-Accel-Expires;

            proxy_hide_header "Cache-Control";
            proxy_hide_header Pragma;
            proxy_hide_header Server;
            proxy_hide_header Request-Context;
            proxy_hide_header X-Powered-By;
            proxy_cache_revalidate on;

            proxy_hide_header X-AspNet-Version;
            proxy_hide_header X-AspNetMvc-Version;
            #proxy_pass_header X-Accel-Expires;


            add_header X-Nginx-Cache-Status $upstream_cache_status;

            proxy_cache_use_stale  error timeout invalid_header updating http_500 http_502 http_503 http_504;
            proxy_cache_bypass $arg_nocache $do_not_cache $http_8X0;
            proxy_no_cache $do_not_cache;

    }

    location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
            proxy_cache_valid 200 120d;
            expires 364d;
            add_header Cache-Control public;
            proxy_pass http://127.0.0.1:8000;
            proxy_cache staticfilecache;
            add_header X-Nginx-Cache-Status $upstream_cache_status;
            proxy_cache_use_stale  error timeout invalid_header updating http_500 http_502 http_503 http_504;
    }

    

Answer 1

Pode ser necessário definir o parâmetro inactive em proxy_cache_path para algo maior que 120d (ou o que você quiser que seu tempo máximo de cache seja realmente). A configuração padrão para inativo é de 10 minutos . Contanto que o URL que você está armazenando em cache seja acessado dentro do período de tempo do parâmetro inativo, seu cache é válido, mas se não for acessado dentro desse período de tempo, ele cairá do cache. Consulte Noções básicas sobre a diretiva nginx proxy_cache_path para obter mais informações.

Acredito que isso está fora da depuração típica do estilo $ upstream_cache_status porque a limpeza do cache não acontece dentro do ciclo de solicitação / resposta. AFAIK um processo de trabalho nginx faz cache de limpeza como uma tarefa de baixa prioridade, se não está fazendo mais nada. Não tenho certeza de onde essa atividade seria mostrada nos logs, mas é provável que ela apareça apenas com uma compilação ativada para depuração.

    

Answer 2

Cache:

Você está ativando proxy_cache no bloco location ou server ?

Por exemplo, algumas configurações no bloco location / dos documentos Nginx .

proxy_cache_path  /var/lib/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=700m;


server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502
                              http_503 http_504;
        proxy_cache_background_update on;
        proxy_cache_lock on;
    # ...
    }

Para o cache funcionar, você precisa de pelo menos as duas configurações obrigatórias:

• proxy_cache_path
• proxy_cache

Se você definir em algum bloco location , tem certeza de que é aquele que deseja armazenar em cache?

Analisando

Se você deseja analisar os hits, você pode criar um log específico para isso:

log_format cache_st '$remote_addr - $upstream_cache_status [$time_local]  '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

E no mesmo bloco server ou location , você pode adicioná-lo como um log secundário, para não perder as outras coisas:

access_log   /var/log/nginx/domain.com.access.log;
access_log   /var/log/nginx/domain.com.cache.log cache_st;

Você pode verificar algumas estatísticas:

HIT vs MISS vs BYPASS vs EXPIRADO

awk '{print $3}' cache.log | sort | uniq -c | sort -r

URLs da MISS :

awk '($3 ~ /MISS/)' cache.log | awk '{print $7}' | sort | uniq -c | sort -r

URLs de BYPASS :

awk '($3 ~ /BYPASS/)' cache.log | awk '{print $7}' | sort | uniq -c | sort -r

MISS vs BYPASS

• MISS ocorre quando um padrão é configurado para armazenar em cache, mas no momento da solicitação não foi armazenado em cache. Na configuração correta, as solicitações subsequentes serão atendidas a partir do cache com base na duração do armazenamento em cache de outros parâmetros.
• BYPASS ocorre quando um padrão foi explicitamente configurado para NÃO usar o cache. por exemplo. ignorando o cache para o usuário conectado. As solicitações subseqüentes também serão ignoradas.

Fonte de análise:  - link

Outra opção para analisar rapidamente via console é usar o GoAccess, um analisador de logs da web em tempo real muito bom, que só precisa de ncurses para funcionar: link

    

Answer 3

O que você está tentando armazenar em cache? Um cms? Uma página estática? Normalmente, se for feito o backup, enviar no-cache, expire -1 ou cache private, você receberá erros. Em caso de cookie, você também terá erros.