Re: Управление кешом - фичареквест
> Тогда не понимаю смысла в доработке... > На ненагруженных проектах, где даже резервированием не "запариваются" > инвалидацию можно сделать через bypass (отправив запрос с БЭ на nginx) > На нагруженных, где подобный сценарий считают слишком затратным, как правило > не шлют все запросы клиента на один FE и метод работать не будет. > Или, есть, конечно, другой вариант: реализовать доработку, а ее "кластерный" > вариант выпустить в платной версии )) Эмм... два запроса связанные с одним кешом как правило выполняются одним и тем же бакендом. конечно если система распределенная полностью, то такая фича и не нужна будет. но в распределенных нагруженных системах и nginx уже никто не применяет ни для чего иного кроме как роутинга http-трафика. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление кешом - фичареквест
> Тема, конечно, старая, и уже "завяла", но: > а как Вы собираетесь инвалидировать кэш если у вас, к примеру, стоит 2 > frontend'а и каждый из них кэширует независимо? > Вот пришёл, к примеру, один юзер на FE1, страница закэшировалась. Второй - на > FE02, страница закэшировалась ещё раз. Потом прошёл какой-то запрос, в ответе > на который была инвалидация по заданному ключу. И этот запрос проксируется > ведь тут фича, очевидно будет для одного FE. то есть юзер должен понимать что кеш сбросится у того FE который стоит перед данным бакендом -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
>>>> кроме
>>>>
>>>> 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: un...@debian.org jabber://un...@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
signature.asc
Description: Digital signature
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
> << если взять nginx с сайта http://nginx.org/en/download.html >>> - этот глюк воспроизводится? если нет - проблема очевидно где. >> да на живом сайте воспроизводится с завидной регулярностью :( > на какой версии воспроизводится BUG, nginx-1.4.2 или nginx-1.5.3 ? > что при этом показывает результат выполнения команды nginx -V ? на версии Debian 1.2.1 а ща тоже самое на версии so:[~]$ /usr/sbin/nginx -V nginx version: nginx/1.4.1 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --with-pcre-jit --with-http_gzip_static_module --with-http_ssl_module --with-ipv6 --without-http_browser_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_zone_module --without-http_memcached_module --without-http_referer_module --without-http_scgi_module --without-http_split_clients_module --with-http_stub_status_module --without-http_ssi_module --without-http_userid_module --without-http_uwsgi_module --add-module=/tmp/buildd/nginx-1.4.1/debian/modules/nginx-echo > On 19.08.2013 9:44, Dmitry E. Oboukhov wrote: >> я писал же: когда поставил nginx-лайт 1.2.1 (тот который без сторонних >> модулей), то ситуация улучшилась настолько что мне даже показалось что >> проблема решена. > тот вариант, который идет в поставке Debian - не подходит. > потому что там есть сторонние модули, даже в варианте light: > Package: nginx-light > THIRD PARTY MODULES: Echo этот модуль может влиять на прорыв кеша? я попробую конечно пересобрать... хм -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
>> кроме >> >> proxy_cache_lock on; >> proxy_cache_use_stale updating; >> >> есть еще директива proxy_cache_lock_timeout и по умолчанию там: >> >> proxy_cache_lock_timeout 5s; >> >> не может быть такой ситуации, что когда "самый наплыв пользователей" >> backend не успевает ответить за 5 секунд? > +1 > Это штатный вариант, когда запросы к одному и тому же > ресурсу могут попасть на бекенд в больших количествах при > используемых настройках. а можно об этом в лог запись писать? тогда бы хоть как-то диагностировать можно было. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
>> кешменеджер запустился, НИ ОДНОЙ ошибки в логах nginx нет. все хорошо. >> потом... бац! на хосте нагрузка ~15-20. >> смотрим в чем дело - апач все поел. >> смотрим на чем - на закешированных запросах: GET /cached/бла/1234 >> >> рестартуем nginx - нагрузка падает. потом в самый наплыв пользователей >> опять... бац: кеш прорвало. >> >> благо что с нагрузкой на хосте 15-20 апач справляется и без кеша. >> сайт тупит конечно, но работает. >> >> а когда кеш живой, то нагрузка 0.8-1. >> >> сейчас поставил nginx-лайт 1.4 (Debian/wheezy).. вчерашний пик >> пользователей пережили вроде без прорыва кеша. >> но правда и 1.2.1 его прорывал тоже не каждый раз. >> >> и самое интересное что когда прорывает кеш в логе ну ни записи. >> просто пришла 1000 запросов. и апач бы должен был выполнить один, а >> ему достается 600 из этой тысячи. > кроме > proxy_cache_lock on; > proxy_cache_use_stale updating; > есть еще директива proxy_cache_lock_timeout и по умолчанию там: > proxy_cache_lock_timeout 5s; тут у меня написано 30s. то есть когда впервые с этой ситуацией столкнулся уже стал крутить все ручки с кешом связанные. > не может быть такой ситуации, что когда "самый наплыв пользователей" > backend не успевает ответить за 5 секунд? даже когда происходит "прорыв" кеша апач укладывается в 5 секунд ответа (по логам nginx собственно это и видно). то есть апач вполне держит нагрузку и без кеша (при LA=15-20). где-то 400-500 запросов в секунду на 10 воркеров апача. то есть где-то 50 в секунду на воркер получается. > в документации совсем не написано как себя в такой ситуации поведет > nginx, возможно он тогда отпускает все клиентские запросы backend ? > P.S. > - этот глюк воспроизводится? если нет - проблема очевидно где. да на живом сайте воспроизводится с завидной регулярностью :( -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
>> >> да, в 1.2.1 прорывается кеш и в случае использования Accel-Expires >> тега и в случае его неиспользования. >> >> сапгрейдил nginx до 1.4. смотрим, ждем. >> >> видимо надо свое кеширование писать, раз даже в nginx не могут его >> запилить чтобы работало :( > Сторонние модули выпилили, или как в прошлый раз? > Ждать, что кеширование будет работать, если в логах вполне > однозначно написано, что из-за стороннего модуля cache manger > умер - несколько наивно. я писал же: когда поставил nginx-лайт 1.2.1 (тот который без сторонних модулей), то ситуация улучшилась настолько что мне даже показалось что проблема решена. кешменеджер запустился, НИ ОДНОЙ ошибки в логах nginx нет. все хорошо. потом... бац! на хосте нагрузка ~15-20. смотрим в чем дело - апач все поел. смотрим на чем - на закешированных запросах: GET /cached/бла/1234 рестартуем nginx - нагрузка падает. потом в самый наплыв пользователей опять... бац: кеш прорвало. благо что с нагрузкой на хосте 15-20 апач справляется и без кеша. сайт тупит конечно, но работает. а когда кеш живой, то нагрузка 0.8-1. сейчас поставил nginx-лайт 1.4 (Debian/wheezy).. вчерашний пик пользователей пережили вроде без прорыва кеша. но правда и 1.2.1 его прорывал тоже не каждый раз. и самое интересное что когда прорывает кеш в логе ну ни записи. просто пришла 1000 запросов. и апач бы должен был выполнить один, а ему достается 600 из этой тысячи. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
>> продолжаю играться с кешированием >> на тестах (в том числе конкурентных, ab) все было хорошо - попробовали >> под нагрузкой. >> nginx 1.2.1 > да видимо есть бага какая-то. > причем похоже бага с обработкой 'X-Accel-Expires' > прорывает кеш периодически и на бакенд идет толпища запросов. > убрал в nginx возможность управлять кешом со стороны бакенда > proxy_ignore_headers 'X-Accel-Expires'; > и стало работать нормально: на бакенд проходит 1 запрос в секунду > на nginx - 500-600. > а когда управляли кешированием с бакенда, всегда выдавая > X-Accel-Expires: 30 > то периодически на бакенд прорывается один и тот же запрос с частотой > 200-300 в секунду (при 500-600 на фронтенде) да, в 1.2.1 прорывается кеш и в случае использования Accel-Expires тега и в случае его неиспользования. сапгрейдил nginx до 1.4. смотрим, ждем. видимо надо свое кеширование писать, раз даже в nginx не могут его запилить чтобы работало :( -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
> продолжаю играться с кешированием > на тестах (в том числе конкурентных, ab) все было хорошо - попробовали > под нагрузкой. > nginx 1.2.1 да видимо есть бага какая-то. причем похоже бага с обработкой 'X-Accel-Expires' прорывает кеш периодически и на бакенд идет толпища запросов. убрал в nginx возможность управлять кешом со стороны бакенда proxy_ignore_headers 'X-Accel-Expires'; и стало работать нормально: на бакенд проходит 1 запрос в секунду на nginx - 500-600. а когда управляли кешированием с бакенда, всегда выдавая X-Accel-Expires: 30 то периодически на бакенд прорывается один и тот же запрос с частотой 200-300 в секунду (при 500-600 на фронтенде) -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
> продолжаю играться с кешированием > на тестах (в том числе конкурентных, ab) все было хорошо - попробовали > под нагрузкой. > nginx 1.2.1 ушел от nginx-extras в nginx-light (Debian) проблема исчезла. видимо какой-то сторонний модуль говнял :( -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Кеширование проблема: перестает кешировать
продолжаю играться с кешированием
на тестах (в том числе конкурентных, ab) все было хорошо - попробовали
под нагрузкой.
nginx 1.2.1
конфиг такой:
proxy_cache_path /var/lib/nginx/proxy levels=1:2 keys_zone=proxy:30m
max_size=1G;
location ~ /cached/ {
proxy_pass http://backend;
proxy_cache proxy;
proxy_buffering on;
proxy_cache_valid 200 60m;
proxy_cache_lockon;
proxy_methodGET;
proxy_cache_use_stale updating;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_headerHost$host;
proxy_set_headerX-Real-IP $remote_addr;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
add_header "X-Taxi-Location" "/cached";
proxy_set_headerCookie '';
proxy_ignore_headers 'Set-Cookie';
proxy_cache_key $uri;
proxy_hide_header 'Set-Cookie';
expires off;
}
Все запросы что имеют в урле /cached/ кешируются на 60m
Но есть проблема.
пока нагрузка небольшая все замечательно:
смотрим логи nginx (grep /cached/) а так же смотрим логи бакенда
(такой же греп). Видим что на nginx приходят сотни запросов, а на
бакенд (апач) единицы.
Все хорошо.
затем повышаем нагрузку и где-то на 100-500 запросов в секунду на апач
начинают "просачиваться" запросы минуя кеш.
то есть нормальное соотношение у нас там если он все кеширует = где-то
1000:1 (то есть на 1000 запросов nginx приходится один на бакенд).
но при работе под нагрузкой соотношение меняется к 1000:500 и местами
даже к 1000:800.
На апаче вижу строго одинаковые запросы (он эту нагрузку держит,
отдает 200'ки). в tcpdump никаких заголовков, касающихся кеша не вижу.
апач всегда выдает заголовок x-accel-expires: 600 для всех ответов по
роуту /cached/.
в error логе nginx ошибок никаких про кеш нет.
правда на старте выдает вот такую фигатень:
2013/07/27 23:53:32 [info] 9945#0: Using 32768KiB of shared memory for push
module in /etc/nginx/nginx.conf:65
2013/07/27 23:53:32 [alert] 9952#0: epoll_ctl(1, 0) failed (1: Operation not
permitted)
2013/07/27 23:53:32 [alert] 9952#0: failed to register channel handler while
initializing push module worker (1: Operation not permitted)
2013/07/27 23:53:32 [alert] 9953#0: epoll_ctl(1, 0) failed (1: Operation not
permitted)
2013/07/27 23:53:32 [alert] 9953#0: failed to register channel handler while
initializing push module worker (1: Operation not permitted)
2013/07/27 23:53:32 [alert] 2232#0: cache manager process 9952 exited with
fatal code 2 and cannot be respawned
В какую сторону покопать?
--
. ''`. Dmitry E. Oboukhov
: :’ : email: un...@debian.org jabber://un...@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
signature.asc
Description: Digital signature
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление кешом - фичареквест
>> нет это совсем не то что в фичареквесте. >> > ... >> >> я хочу получить механизм внутри обработчика сбросить кеш на другом >> роуте. >> как вариант - выдать хидер с урлом кеш на котором надо сбросить. >> >> а директивы в конфиге = это не программа это набор условий :) >> > я раньше решал похожую проблему с помощью модуля ngx_cache_purge ( > http://wiki.nginx.org/CachePurgeChs ). создавал в nginx специальный > локейшн (/purge/), при обращении к которому удалялся из кеша указанный > элемент. Т.е. после изменения в базе, запрос по этому локейшну делает > само приложение (для wordpress есть специальный плагин). Подробнее (с > конфигами) можно почитать тут: > http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html > http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html > но теперь, я бы попытался реализовать соответствующий функционал без > стороннего модуля, а только директивой proxy_cache_bypass. proxy_cache_bypass ведь не дает того функционала о котором я говорю: когда один роут сбрасывает кеш на другом роуте. > Таким образом, применяя предложенную мной схему, вместо того чтобы > просто отдать nginx страницу с заголовком X-Cache-Invalid: > "/users/top/123?all=yes", вам придётся сначала сделать запрос из > приложения по адресу /purge/users/top/123?all=yes и элемент кеша > обновится. я посмотрю внутрь модуля. сложно его доработать до того функционала что я говорю? -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление кешом - фичареквест
>> X-Cache-Invalid: "/users/top/123?all=yes" >> >> - определяет что с данного момента определенный набор страниц >> находящихся в кеше (набор = если несколько таких заголовков выдали) >> невалиден. >> >> Тогда если бакенд выдал такой заголовок (или несколько таких >> заголовков), чтобы nginx по факту выдачи такого ответа сбросил кеши, >> связанные с данными урлами? > Помнится мне, когда-то давно Игорь писал в рассылку, что планирует > нечто подобное сделать. А сейчас даже есть draft RFC на > аналогичную тему, тут: > http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-04 да похоже. только я не понял имеется ли ввиду инвалидация только тех урлов, что выданы в директиве Link либо всех включая Location, хотя это не сильно важно. важно что с подобной фичей можно было бы строить приложения, которые бы сильно могли разгружать бакенд. кстати почитав RFC можно дополнить: хорошо бы не просто выпиливать конкретные страницы из кеша, а еще и выпиливать их по маске типа Invalid: /users/list/[1-9][0-9]*/abc но это будет конфликтовать конечно с тем что в качестве ключа в БД используется md5 от урла а не урл > Я, правда, сомневаюсь, что draft взлетит, но вообще > функциональность, как мне кажется, интересная. > С точки зрения реализации в nginx'е есть, правда, один нюанс: > ключ кеширования может задаваться произвольно, и не так просто > вычислить, что именно нужно убрать из кеша. если юзер оперировать будет урлами (всегда) а ключ кеширования будет вычисляться на nginx то все кроме масок может быть реализовано. но в принципе кешируются именно те страницы которые относятся сразу к многим пользователям, поэтому маски сильно не нужны. а вот инвалидация кеша по произвольному ответу бакенда уже позволила бы много чего интересного делать народ, кто взялся бы такой плагин написать? я бы мог инвестировать в него, скажем 500$ из своих скромных личных средств :) или лучше патч, чтобы его в апстрим положить :) -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление кешом - фичареквест
>>> удалить элемент из кеша можно директивой >>> http://nginx.org/r/proxy_cache_bypass/ru по ключу (т.е. новый элемент >>> возмётся не из кеша, но закешируется) >> >> нет это совсем не то что в фичареквесте. >> > ... >> >> я хочу получить механизм внутри обработчика сбросить кеш на другом >> роуте. >> как вариант - выдать хидер с урлом кеш на котором надо сбросить. >> >> а директивы в конфиге = это не программа это набор условий :) >> > я раньше решал похожую проблему с помощью модуля ngx_cache_purge ( > http://wiki.nginx.org/CachePurgeChs ). создавал в nginx специальный > локейшн (/purge/), при обращении к которому удалялся из кеша указанный > элемент. Т.е. после изменения в базе, запрос по этому локейшну делает > само приложение (для wordpress есть специальный плагин). Подробнее (с > конфигами) можно почитать тут: > http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050061.html > http://mailman.nginx.org/pipermail/nginx-ru/2012-December/049347.html > но теперь, я бы попытался реализовать соответствующий функционал без > стороннего модуля, а только директивой proxy_cache_bypass. > Таким образом, применяя предложенную мной схему, вместо того чтобы > просто отдать nginx страницу с заголовком X-Cache-Invalid: > "/users/top/123?all=yes", вам придётся сначала сделать запрос из > приложения по адресу /purge/users/top/123?all=yes и элемент кеша > обновится. тогда уж проще идти по следующему пути: 1. настраиваем nginx на работу с мемкешом 2. реализуем в приложении тот же алгоритм взятия md5sum от урла что и в nginx (чтобы получать id ключа в мемкеше) 3. удаляем ключи в мемкеше если надо 4. PROFIT http-запрос из приложения по адресу представляется очень тяжеловесным решением. мемкеш хотя-бы персистентное соединение держать можно. а вот зная четко что у бакенда с nginx уже установлена связь (отвечать бакенд должен) то выдать по этой связи инструкцию управления кешом по моему наиболее просто. а управлять кешом по урлам - это для кронскриптов/демонов/прочих скриптов. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление кешом - фичареквест
>> а можно сюда добавить еще хидер, например: >> >> X-Cache-Invalid: "/users/top/123?all=yes" >> >> - определяет что с данного момента определенный набор страниц >> находящихся в кеше (набор = если несколько таких заголовков выдали) >> невалиден. >> >> Тогда если бакенд выдал такой заголовок (или несколько таких >> заголовков), чтобы nginx по факту выдачи такого ответа сбросил кеши, >> связанные с данными урлами? > удалить элемент из кеша можно директивой > http://nginx.org/r/proxy_cache_bypass/ru по ключу (т.е. новый элемент > возмётся не из кеша, но закешируется) нет это совсем не то что в фичареквесте. вот имеется nginx. делаем GET/POST запрос по роуту /route1/path. в location прописано что кеширование по данному роуту до 30 минут. бакенд выдает X-Accel-Expires: 120 в ответ nginx создает кеш-запись о /route1/path, затем все последующие аналогичные запросы к /route1/path приведут к тому что nginx отвечать будет из кеша в течение 2 минут. теперь через 40 секунд производится другой запрос GET/POST итп /route_other/path_other/. этот запрос транслируется может быть даже другому бакенду. и вот в обработчике этого запроса производятся какие-то изменения в БД, которые приведут в частности к тому что по предыдущему роуту /route1/path бакенд начнет выдавать совсем другие данные. то есть с момента запроса роута /route_other/path_other/ кеш для роута /route1/path должен быть сброшен и обработчик /route_other/path_other/ это знает. я хочу получить механизм внутри обработчика сбросить кеш на другом роуте. как вариант - выдать хидер с урлом кеш на котором надо сбросить. а директивы в конфиге = это не программа это набор условий :) -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Управление кешом - фичареквест
поигрался немного с кешами. интересно, включаем кеш для location'а на скажем 0-30 минут и далее бакенд определяет что данную страницу надо закешировать на скажем 20 секунд выдавая заголовок X-Accel-Expires: 20. это классная фича! но вот если посмотреть на любой сайт с кешированием, то можно увидеть что какую-то информацию мы можем выдать в кеш, но при этом кеш валиден будет *до определенного действия пользователя*. например (утопический пример) мы на сайте кешируем список пользователей написавших больше всего сообщений (ТОП по пользователям). понятное дело, такой ТОП меняется редко и можно смело ему выдать скажем 10 минут время жизни кеша и все будет хорошо. но допустим у нас задача есть чтобы этот ТОП выводился более качественно. становится ТОП'ом другой пользователь (входит в ТОП10) и сразу картинка перестраивается (без лага в 0-10 минут). для такой задачи просто определение времени жизни кеширования из бакенда не подойдет. еще нужно иметь возможность сказать что кеш невалиден nginx'у. и вот тут фичареквест добавить опцию (насколько я понимаю не должно быть сложным): у нас есть один хидер на управление кешом: X-Accel-Expires: [ секунд | @секунд ] - определяет сколько времени данная страница может находиться в кеше а можно сюда добавить еще хидер, например: X-Cache-Invalid: "/users/top/123?all=yes" - определяет что с данного момента определенный набор страниц находящихся в кеше (набор = если несколько таких заголовков выдали) невалиден. Тогда если бакенд выдал такой заголовок (или несколько таких заголовков), чтобы nginx по факту выдачи такого ответа сбросил кеши, связанные с данными урлами? -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Таймауты на бакенде
столкнулся тут с проблемкой
выкатили некое обновление, которое привело к росту нагрузки в
несколько раз. огребли 504.
стали анализировать логи,
nginx отдает 504 по причине того что бакенд дескать не отвечает, время
обработки запроса у него 60 секунд:
128.69.168.54 - - [25/Jul/2013:09:37:00 +0400] "POST /dispatcher/ajax/drivers
HTTP/1.1" 504 584 "http://бла-бла/dispatcher"; "Mozilla/5.0 (Windows NT 6.1)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36"
[60.000 : 60.000]
в логе ошибок при этом:
2013/07/25 09:37:00 [error] 4832#0: *425146128 upstream timed out (110:
Connection timed out) while connecting to upstream, client: 128.69.168.54,
server: бла-бла.ru, request: "POST /dispatcher/ajax/drivers HTTP/1.1",
upstream: "http://127.0.0.1:81/dispatcher/ajax/drivers";, host: "бла-бла",
referrer: "http://бла-бла/dispatcher";
(в конце логов добавлены '[$request_time : $upstream_response_time]')
ну и вроде как бы очевидно, бакенд не справляется надо их количество
увеличить сперва. Откатились пока на старую версию, нагрузки меньше.
все ок.
далее поглядел я в логи апача, а там такая интересная хрень:
...
[Thu Jul 25 07:52:55 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:09 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:16 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:29 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:43 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:43 2013] [info] [client 127.0.0.1] Request header read timeout
[Thu Jul 25 07:53:43 2013] [info] [client 127.0.0.1] Request header read timeout
и так на периоде 4 часа
...
то есть получается что в то же самое время (все это на периоде 4 часа
примерно было) когда nginx отдавал 504 через 60 секунд после начала
работы жалуясь на 'upstream timed out' в это же время апач жаловался
что к нему коннектятся но ничего не просят.
nginx'ов - 4 вокрера конфиг для данного роута простейший:
location / {
proxy_pass http://backend;
proxy_set_headerHost$host;
proxy_set_headerX-Real-IP $remote_addr;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
more_clear_input_headers 'Transfer-Encoding';
proxy_set_header X-Forwarded-Protocol $scheme;
}
--
. ''`. Dmitry E. Oboukhov
: :’ : email: un...@debian.org jabber://un...@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
