Комментарии 65
Спс. А как удобнее сбросить кеш, например, при изменении страницы через админку?
+1
Для этого нужно proxy_no_cache заменить на
и при обновлении страницы через админку делать внутренний запрос к nginx без куки, но с заголовком
proxy_no_cache $cookie_session $http_x_update;
и при обновлении страницы через админку делать внутренний запрос к nginx без куки, но с заголовком
X-Update: 1
+4
Имхо при этом страница будет не закэширована, но сам кэш при этом не измениться
0
Согласно вики на английском кеш изменится. В русской документации написано ровно об обратном. Возможно, вы правы и вместо proxy_no_cache следует использовать proxy_cache_bypass. Проверю.
0
Если использовать не proxy_no_cache, а
то кеш будет обновляться. Только что проверил на 1.0.5.
proxy_cache_bypass $cookie_session $http_x_update;
то кеш будет обновляться. Только что проверил на 1.0.5.
0
Если у вас апдейты несрочные, то ставьте время жизни кеша в одну минуту.
0
Если Вы хотите удалять кэш из админки, Вы также можете добавить в секцию локейшн строку:
fastcgi_cache_key "$host$request_uri" или proxy_cache_key "$host$request_uri", смотря что Вы используете, и в указанной папке хранения кэша, кэш страниц будет лежать под именем:
md5($host.$request_uri).
Пример:
зайдя по ссылке: habrahabr.ru/blogs/nginx/124684/
кэш будет лежать в указанной папке с именем: md5('habrahabr.ru/blogs/nginx/124684/');
fastcgi_cache_key "$host$request_uri" или proxy_cache_key "$host$request_uri", смотря что Вы используете, и в указанной папке хранения кэша, кэш страниц будет лежать под именем:
md5($host.$request_uri).
Пример:
зайдя по ссылке: habrahabr.ru/blogs/nginx/124684/
кэш будет лежать в указанной папке с именем: md5('habrahabr.ru/blogs/nginx/124684/');
+1
Сысоев обещал это приделать, но похоже руки так и не дошли.
Я лично убиваю кэш и рестартую nginx
Я лично убиваю кэш и рестартую nginx
0
Что значит не сделал? Я так делаю.
0
Как так? Удаляете файлы?
Речь шла о более удобных и правильных способах управлением кэшем — сигналом хотя бы или хитрым запросом.
Речь шла о более удобных и правильных способах управлением кэшем — сигналом хотя бы или хитрым запросом.
+1
А что Вам мешает реализовать свою схему очереди? Сделайте стек очередей и отправьте туда сигнал на удаление кэша, что Вам это мешает сделать?
А по поводу сигнала nginx-у, как? Он веть хранит файлы под хэшем, он не может пробежаться даже регулярке: site.zone/news/*.
Поэтому самому удалять это самый простой и не сильно уж и долгий процесс, тем более если Вы кэш будете хранить в памяти.
А по поводу сигнала nginx-у, как? Он веть хранит файлы под хэшем, он не может пробежаться даже регулярке: site.zone/news/*.
Поэтому самому удалять это самый простой и не сильно уж и долгий процесс, тем более если Вы кэш будете хранить в памяти.
0
очереди чего?
у nginx-а есть понятие зоны для кэша. Меня вполне устроит сброс таймингов для зоны. Процесс же удаления зависит от количества удаляемого. С учетом того что для ускорения работы делают вложенность, то это совсем не равноценно сбросу некторых таймеров внутри сервера.
Тут мне пришла в голову мысль что может быть таймеры на самом деле — это время модификации файла/ключа. Надо будет попробовать их состарить в качестве сброса кэша.
Но все равно это не снимает вопроса в «первона#е» — как через админку сайта сбросить ему кэш. Приходиться рыться в конфигах и вытаскивать путь под doc_root-ом, что уже плохо. А потом там шерудить, что совсем не хорошо. Было бы намного удобнее иметь возможность задать ключ для сброса кэша в пределах действия proxy_cache — для location или server.
Типа пусть каждый занимается своим делом. Управлять кэшем — дело как раз для proxy модуля nginx, а не всяких приблудных скриптов.
у nginx-а есть понятие зоны для кэша. Меня вполне устроит сброс таймингов для зоны. Процесс же удаления зависит от количества удаляемого. С учетом того что для ускорения работы делают вложенность, то это совсем не равноценно сбросу некторых таймеров внутри сервера.
Тут мне пришла в голову мысль что может быть таймеры на самом деле — это время модификации файла/ключа. Надо будет попробовать их состарить в качестве сброса кэша.
Но все равно это не снимает вопроса в «первона#е» — как через админку сайта сбросить ему кэш. Приходиться рыться в конфигах и вытаскивать путь под doc_root-ом, что уже плохо. А потом там шерудить, что совсем не хорошо. Было бы намного удобнее иметь возможность задать ключ для сброса кэша в пределах действия proxy_cache — для location или server.
Типа пусть каждый занимается своим делом. Управлять кэшем — дело как раз для proxy модуля nginx, а не всяких приблудных скриптов.
0
Если страницы надо удалять из кэша поштучно, то есть модуль, который это дело делает (директива proxy_cache_purge), у меня настроена хитрая комбинация символов, их надо дописать в урл, чтобы удалить из кэша конкретную страницу.
Если массово, то зная список ссылок можно узнать список путей на диске (директива proxy_cache_key) и удалить их скриптом.
Если массово, то зная список ссылок можно узнать список путей на диске (директива proxy_cache_key) и удалить их скриптом.
+1
Правильно будет использовать директиву не proxy_no_cache, а
Например, можно поставить обновление главной страницы раз в минуту через curl:
proxy_cache_bypass $cookie_session $http_x_update;
Например, можно поставить обновление главной страницы раз в минуту через curl:
curl -H "X-Update: 1" www.example.com
0
Добавлю ссылку по теме: Подводные камни при использовании кэширования в nginx.
+6
Что-то вы все переврали.
Объясню как есть на самом деле:
1. Nginx кеширует ответы от бэкэнда, которые он разрешил кешировать. Nginx смотрит на заголовки Cache-control, Expires.
2. В php, если стартует сессия, то автоматом добавляются заголовки
Объясню как есть на самом деле:
1. Nginx кеширует ответы от бэкэнда, которые он разрешил кешировать. Nginx смотрит на заголовки Cache-control, Expires.
2. В php, если стартует сессия, то автоматом добавляются заголовки
+2
(само отправилось)
автоматом добавляются заголовки:
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Соответственно nginx такой ответ не закеширует.
3. Соответственно, как вы правильно сказали, чтобы кеш работал, не надо стартовать сессию.
А строчку «proxy_ignore_headers Expires Cache-Control;» как раз нужно убрать, тогда всё будет работать правильно — там где нет сессии и нет заголовков закешируется, там где есть заголовки будет без кеша.
Кстати
автоматом добавляются заголовки:
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Соответственно nginx такой ответ не закеширует.
3. Соответственно, как вы правильно сказали, чтобы кеш работал, не надо стартовать сессию.
А строчку «proxy_ignore_headers Expires Cache-Control;» как раз нужно убрать, тогда всё будет работать правильно — там где нет сессии и нет заголовков закешируется, там где есть заголовки будет без кеша.
Кстати
0
Если у вас есть время влезать в исходники какого-то случайно выбранного сайта, написанного бог знает когда бог знает кем — убирайте
У меня на это времени и сил нет, в жизни есть занятия интересней, чем копаться в чужом коде без явной необходимости, которой здесь нет.
proxy_ignore_headers
и ищите, где там в коде сайта задаются заголовки Cache-Control
и Expires
чтобы их убрать. У меня на это времени и сил нет, в жизни есть занятия интересней, чем копаться в чужом коде без явной необходимости, которой здесь нет.
0
Вы не совсем правы, дело в том, что если у Вас отдаются изображения через тот же nginx, то у Вас возникнет такая ситуация, что все картинки будут тоже закешированны, т.к. он сам добавляет эти заголовки для браузера.
Сам столкнулся с подобной проблемой, не мог понять почему у меня уменьшался объем на ШДД, а nginx просто параллельно еще кешировал и сами изображения, тоесть просто копировал их в папку для кеша.
Сам столкнулся с подобной проблемой, не мог понять почему у меня уменьшался объем на ШДД, а nginx просто параллельно еще кешировал и сами изображения, тоесть просто копировал их в папку для кеша.
0
Для картинок лучше отдельный location без кеширования но с expires и всем, что нужно:
location ~* \.(jpg|jpeg|gif|png|ico|css|js|swf)$ {
expires max;
root /var/www;
}
0
Для статики вообще желательно использовать отдельный субдомен, чтобы не заставлять его бегать по регуляркам, я лично так делаю.
Конечно в локейшине можно и отключить его, просто я столкнулся с такой проблемой. а до этого не знал о этом, сейчас просто поделился.
Что касается приведенного Вами примера, он тоже не всегда хорош, у меня есть изображения которые гинерятся скриптом.
Конечно в локейшине можно и отключить его, просто я столкнулся с такой проблемой. а до этого не знал о этом, сейчас просто поделился.
Что касается приведенного Вами примера, он тоже не всегда хорош, у меня есть изображения которые гинерятся скриптом.
0
Про статику никто не говорил :)
Если статика на том же сервере, то её нужно выносить в отдельный локейшен, чтобы она бралась напрямую с диска, если она на другом серваке, то можно и закешировать, чтобы не гонять между серваками и не напрягать бэкендовый апач.
Если статика на том же сервере, то её нужно выносить в отдельный локейшен, чтобы она бралась напрямую с диска, если она на другом серваке, то можно и закешировать, чтобы не гонять между серваками и не напрягать бэкендовый апач.
0
Поэтому proxy_ignore_headers Expires Cache-Control; желателен.
0
Прочитайте, пожалуйста, документацию в разделе про
proxy_ignore_headers
и ещё раз скажите мне: где я что переврал?0
На самом деле можно и не указывать proxy_cache_bypass $cookie_session; proxy_no_cache $cookie_session; т.к. nginx не кэширует если видит заголовок Set-Cookie. Да, в документации про это ни слова :)
0
Эти заголовки нужны чтобы клиенты, у которых в запросе есть заголовок Cookie с куки session проходили мимо кеша. К заголовку Set-Cookie эти директивы отношения не имеют.
0
еще раз. nginx по дефолту не будет кэшировать если увидит в ответе клиенту заголовок Set-Cookie внезависимости от того что там в proxy_no_cache. это поведение можно изменить добавив proxy_ignore_headers «Set-Cookie»;
0
И правильно делает. Зачем оно нужно — кешировать запросы в которых есть Set-Cookie? Вдруг это вы, пытаетесь зайти на сайт, чтобы оставить комментарий?
0
а может вы гуглобот и вам побоку на всякие куки, но вы приходите регулярно за одним и тем же :)
в общем я лишь хотел указать на избыточность proxy_no_cache $cookie_session; и на неполноту документации.
в общем я лишь хотел указать на избыточность proxy_no_cache $cookie_session; и на неполноту документации.
0
А если такая ситуация:
* Захожу на какую-то страницу типа about. Она кешируется
* Затем я логинюсь, страница логина не кешируется из-за Set-Cookie
* захожу снова на about — и получаю кешированную струницу??
А это не всегда желательный эффект, ведь где нибудь может быть написано Hello Guest / Hello yngvie
* Захожу на какую-то страницу типа about. Она кешируется
* Затем я логинюсь, страница логина не кешируется из-за Set-Cookie
* захожу снова на about — и получаю кешированную струницу??
А это не всегда желательный эффект, ведь где нибудь может быть написано Hello Guest / Hello yngvie
0
Тут уже проверяйте кукисы в конфиге nginx и если они есть, определенная кукиса, то не юзайте кэш.
0
Сложнее. Если кэшировать страницы с Set-Cookie, то вы получите куки другого пользователя, который входил на сайт до вас. Потому nginx по-умолчанию не кэширует запросы в которых есть Set-Cookie.
0
Так можно сделать кеш с куками для каждого отдельного юзера.
Сейчас мсто на хостингах резиновое, ssd, все дела.
Сейчас мсто на хостингах резиновое, ssd, все дела.
0
proxy_cache_bypass $cookie_session; нужен
0
Старт сессии при POST-запросе? Ужасный совет. Сколько же проблем будет, когда об этом все забудут.
+1
Конечно, особенно когда об этом забудут те разработчики, что писали пять лет назад некий сайт, внезапно ставший популярным. Если вы на своём сайте можете сделать правильно и если у вас есть время сделать как надо — этот совет не для вас.
0
Правильно нужно делать всегда. Отладка плохонаписанного кода или внесение в него новой функциональности занимеат куда больше веремени нежели написание правильного кода.
POST-запрос не означает начало новой сессии. Это допущение не верно. Кроме того, аутентификация может осуществляться и GET-запросом (напрмер OpenID).
А задача решается 2-мя фунциями/методами: get*/set*. get* получает значение из $_SESSION[], при этом, если сессия не существует, то ничего не стартуется, а возвращается какое-то пустое значение. set* устанавливает значение, при этом стартует сессию.
POST-запрос не означает начало новой сессии. Это допущение не верно. Кроме того, аутентификация может осуществляться и GET-запросом (напрмер OpenID).
А задача решается 2-мя фунциями/методами: get*/set*. get* получает значение из $_SESSION[], при этом, если сессия не существует, то ничего не стартуется, а возвращается какое-то пустое значение. set* устанавливает значение, при этом стартует сессию.
-1
Задача так не решается если перед вами сайт, который написан бог знает когда, бог знает кем, а заказчик не заинтересован оплачивать ваше время на глубокую переработку сайта. Выше я писал что в жизни есть занятия интересней, чем копаться в чужом коде без явной необходимости, которой здесь нет, и тем более без оплаты. Вы готовы работать бесплатно? Я — нет.
0
Такие условия очень желательно оговаривать в статье.
+1
В начале статьи написано что «редкий сайт нельзя довести.» Довести — значит изменить до определенного состояния (словарь Ушакова). Дальше написано о том, что этот метод применим к большинству сайтов. Большинство сайтов на PHP — сами знаете какое. По-моему всё должно быть понятно.
0
А зачем не стартовать сессию? Можно же просто при логине добавить куки LOGINED или там ADMIN и если она есть отдавать напрямую? По моему легче в метод авторизации добавить установку куки чем из всего сайта выпилить сессии — если я не админ это не значит что они мне не нужны.
-2
Если вы не стартуете сессию, то как в вашем интернет-магазине будет работать корзина?
Этот рецепт подходит для любых сайтов, использующих штатные сессии.
Этот рецепт подходит для любых сайтов, использующих штатные сессии.
0
«Logined» — это на каком языке?
0
Gramar nazi? А мне так нравится:) оно из за того разве не скомпилится или не выполнится?
0
Ну, это как говорить, что безграмотно написанное и так понятно.
Впрочем, не мне Вас судить, Вы правы.
www.flickr.com/photos/highglosshighs/2491131525/
Впрочем, не мне Вас судить, Вы правы.
www.flickr.com/photos/highglosshighs/2491131525/
0
НЛО прилетело и опубликовало эту надпись здесь
Уговорили :) Теперь буду использовать только рассово верную форму LOGGEDIN. Скажите, а вы пользуетесь словом «гуглить», ведь «to google» сам не так давно стал verb'ом?
0
НЛО прилетело и опубликовало эту надпись здесь
Нам нужно защитить его от всплесков посещаемости
Всплески посещаемости — это же хорошо, не надо от них защищать, надо к ним готовить =)
+1
Это просто чудо какое-то!
Правда, не сразу получилось настроить — был затык на уровне прав записи юзера www-data в папку с кешем.
Но когда заработало, то всё залетало.
pS. Важно помнить (было выше в коментах), что ключ кеша строится как MD5(Url), поэтому если такой кеш настроить сразу на несколько сайтов, одиноковый УРЛ на разных сайтах будет давать одинаковый результат — ту страницу, что первой попала в кеш (например, индесная страница с УРЛом "/")
Правда, не сразу получилось настроить — был затык на уровне прав записи юзера www-data в папку с кешем.
Но когда заработало, то всё залетало.
pS. Важно помнить (было выше в коментах), что ключ кеша строится как MD5(Url), поэтому если такой кеш настроить сразу на несколько сайтов, одиноковый УРЛ на разных сайтах будет давать одинаковый результат — ту страницу, что первой попала в кеш (например, индесная страница с УРЛом "/")
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прозрачное кэширование в nginx для всех и каждого