кэширование в nginx+fastcgi

Посмотрите может в сторону memcached?

Мне кажется разумнее впилить кэш непосредственно в бекэнд (в ваш код). Кэшировать динамический контент nginx-ом вообще старнная идея, ИМХО.
Если динамический контент не особо динамический (редко меняется, не персонализируется), и при этом очень долго генерируется то можно вообще генерировать бекендом статический HTML, класть его в файловую систему и отдавать nginx-ом как статику. Ну и перегенерировать по крону или при внесении изменений.

Спасибо, но предложения решить проблему на уровне бэкэнда - не подходят. Там настоящие авгиевы конюшни, которые сейчас разгребать никто не будет. Существующий кэш nginx нас вполне устраивает, за исключением того, что я описал выше - изредка (во время обновления кэша) у клиента страница будет открываться с минуту. Мы хотим в это время клиенту отдавать старую версию из кэша, чтобы он не ждал. Это возможно? По поводу сайта скажу следующее - user-generated контента там практически нет. А то, что наши какие-то изменения/добавления станут доступны пользователям не немедленно, а через (скажем) час - мы готовы с этим смириться. Может, как-то можно решить задачу двумя последовательно работающими инстансами nginx, каждый со своим кэшем?

 proxy_cache STATIC;

         proxy_cache_valid 200 301 302 304 24h;
         proxy_cache_use_stale error timeout invalid_header updating;
         proxy_connect_timeout 1000ms;

Попробуй так. Кеш живёт сутки, отдаётся в случае недоступности бэкенда в течении секунды.

Например можно написать приложение-прокси которое будет получать запросы от пользователя, отдавать ответы из кэша и перенаправлять запрос (можно не каждый, а например каждый 10-й, или раз в n минут (придётся хранить время последней проверки кэша)) собственно бекенду, если ответ бекенда отличается от того что в кеше, кэш обновляется.

Возможно подобная логика уже реализована в самом nginx или каких-то его модулях.

Хорошая мысль. Но, кое в чем я бы вас поправил и дополнил: 1) Вы забыли упомянуть, что это второй сервер nginx надо настроить. 2) Также, я бы поставил proxy_cache_valid 1h а не 24h; 3) не proxy_connect_timeout а proxy_read_timeout. Ведь это он сработает, когда первый сервер пошлет запрос бэкэнду и будет ждать ответа долго. Но, тут не уверен на 100% какой именно таймаут сработает. 4) А на первом сервере, где у меня fastcgi со своим кэшем, я бы поставил fastcgi_ignore_client_abort on; Что скажете?

Люблю, когда меня поправляют :)

Пункт один. Да, так красивее, согласен.
Пункт два. Сутки я указал в качестве примера, решайте, какое время жизни кеша вас устраивает.
Пункт три. Надо проверять, но лучше ИМХО добавить оба варианта. Хотя вроде ваш вариант правильнее.
Пункт четыре. Тут не могу сказать ничего умного, ждём спецов по фастцги, да.

И удачи в настройке :)

еще можно скрипт написать, чтоб находил в кеше объекты, у которых время оставшейся жизни меньше 30 мин и их переспрашивал (*) у nginx, чтоб тот переспрашивал у бакенда и обновлял кеш. * - для таких запросов можно заюзать спец хедер и сказать nginx'u чтоб не брал из кеша ответ, но сохранял в кеш: fastcgi_cache_bypass

спасибо! респект

По-моему, Вам нужен не nginx, а squid перед nginx.

Настроил все, как тут обсудили. Два инстанса nginx, у каждого свой кэш. Все работает, как надо. Но, тут обнаружился неожиданный эффект, который перечеркивает всю идею. А именно - если страницы нет в кэше ни одного из серверов, т.е. ее еще не запрашивали - то при запросе внешний сервер немедленно вернет 504 Gateway Time-out. Да, в это время будет выполняться fastcgi-запрос, потом заполняться кэш внутреннего сервера для этой страницы. Но, пользователю от этого не легче. Ошибка сайта вот она :(

Ну не предназначен nginx для такого. Лет 10 назад я в похожем режиме squid настраивал, но не как web-акселератор. http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_connect_ti... - вот это как в nginx работает? Можно выставить в 5 минут? Если нельзя, можно ли поковырять сорцы и таки выставить в 5 минут?

как бы squid тут помог?