Nginx fastcgi cache HIT vs STALE
У меня странная проблема с микрокешем nginx. Когда nginx обслуживает УСТАРЕВШИЙ контент, это занимает слишком много времени. Моя фактическая часть микроча в конфигурации:
...
fastcgi_cache biznisto.sk;
fastcgi_cache_bypass $skip_cache;
fastcgi_cache_key "$scheme$request_method$host$request_uri$rt_session";
fastcgi_cache_valid 200 301 302 5m;
fastcgi_cache_use_stale updating error timeout invalid_header http_500;
fastcgi_cache_lock on;
fastcgi_cache_revalidate on;
fastcgi_cache_background_update on;
fastcgi_pass_header Set-Cookie;
fastcgi_pass_header Cookie;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
add_header X-Cache $upstream_cache_status;
...
Экраны УСТАРЕЛИ - подождите 565 мс 
HIT - подождите 59 мс 
Какие-либо предложения? Спасибо
В fastcgi_cache_background_update Директива позволяет обновлять просроченный элемент кеша, пока устаревший кешированный ответ возвращается клиенту.
Однако, если ответ полностью возвращен, но обновление еще не завершено, это приведет к задержке последующих действий, включая обработку дополнительных запросов в том же соединении и / или закрытие соединения.
Такое поведение гарантирует, что:
- клиент не может накладывать неконтролируемую нагрузку на сервер, предполагая наличие различных ограничений, таких как limit_conn
- в целом работа обычно лучше, а в худшем случае не хуже, чем без фонового обновления.