Re: Кеширование проблема: перестает кешировать

[Dmitry E. Oboukhov]

>>>> кроме
>>>> 
>>>> proxy_cache_lock      on;
>>>> proxy_cache_use_stale updating;
>>>> 
>>>> есть еще директива proxy_cache_lock_timeout и по умолчанию там:
>>>> 
>>>> proxy_cache_lock_timeout 5s;
>>>> 
>>>> не может быть такой ситуации, что когда "самый наплыв пользователей"
>>>> backend не успевает ответить за 5 секунд?
>> 
>>> +1
>> 
>>> Это штатный вариант, когда запросы к одному и тому же
>>> ресурсу могут попасть на бекенд в больших количествах при
>>> используемых настройках.
>> 
>> а можно об этом в лог запись писать? тогда бы хоть как-то
>> диагностировать можно было.

> Сейчас оно пишется на уровне debug.
> Возможно имеет смысл повысить где-нибудь до info:

> diff --git a/src/http/ngx_http_file_cache.c b/src/http/ngx_http_file_cache.c
> --- a/src/http/ngx_http_file_cache.c
> +++ b/src/http/ngx_http_file_cache.c
> @@ -445,8 +445,8 @@ ngx_http_file_cache_lock_wait_handler(ng
> timer = c->wait_time - ngx_current_msec;

> if ((ngx_msec_int_t) timer <= 0) {
> -        ngx_log_debug0(NGX_LOG_DEBUG_HTTP, ev->log, 0,
> -                       "http file cache lock timeout");
> +        ngx_log_error(NGX_LOG_INFO, ev->log, 0,
> +                      "cache lock timeout");
c->> lock = 0;
> goto wakeup;
> }


я сделал proxy_cache_lock_timeout равным 300 секунд
больше времени 504 ошибки в 5 раз.

все равно кеш прорывается.
причем в момент прорыва кеша сквозь него идут отнюдь не все одинаковые
запросы, а запросы с разными ID

то есть 
/cached/order/123
/cached/order/124
/cached/order/123
/cached/order/125
итп

то есть прогрепать в nginx /order/125 и в apache тот же урл будет
соотношение 2:1. то есть где-то половина проходит сквозь кеш.


и прорывается кеш через время работы под нагрузкой меньшее нежели 300
секунд. таким образом проблема не в локтаймауте.

ну допустим один запрос бы втупил, ну два.
но десятки/сотни разных запросов, при том что апач забрав весь CPU
контент отдает (nginx в логах ни одной 504 не показывает) с той
скоростью с какой клиенты спрашивают.

-- 

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera at debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130819/a243221e/attachment-0001.bin>