On Tue, 15 Mar 2005, Andrew Velikoredchanin wrote:
Igor Sysoev пишет:
On Tue, 15 Mar 2005, Andrew Velikoredchanin wrote:
Igor Sysoev пишет:
On Tue, 15 Mar 2005, Andrew Velikoredchanin wrote:
Igor Sysoev пишет:
On Tue, 15 Mar 2005, Andrew Velikoredchanin wrote:
Igor Sysoev пишет:
On Tue, 15 Mar 2005, Andrew Velikoredchanin wrote:
Boguk Maxim пишет:
Генератор статического HTML и кеширование с возможностью сброса
отдельных
документов по инициативе backend почти одно и тоже.
При этом кеширование не генерирует заведомо не используемые
страницы в
отличии от генераторов статического html.
В общем реально надо механизм сброса части кеша по regexp по
инициативе
backend вот.
(полный сброс не предлагать при обьеме кеша 10Gb+ :))
Мне бы тоже пригодилось.
Ну, скажем, не со стороны бэкэнда, а со стороны вообще. :) Как
вариант - введение условий либо в механизм кэша, либо в mod_rewrite.
Кстати, Игорь. Если делать механизм условного кэширования на основе
времени спец. файла и времени кэша текущего файла, то надо учитывать
что путь к спец. файлу должен строиться на основе url. Только вот
без regexp думаю, здесь не обойтись. Т.к. при необходимости введения
спец. файла для каталогов нужно иметь возможность указывать не весь
url, а с учетом уровня вложенности.
Файлы ограничивают использование одной машиной. regex'ы использовать
нереально. Я вижу такое решение: нужно добавлять в заголовок ответа
ключ(и),
от которого зависит кэширование. Запросы, после которых часть ответов
становятся неверными (например, POST'ы), должны передавать такой же
ключ.
Эти ключи будут храниться в своём кеше.
Игорь, извини, но ничего не понял. Как в таком режиме из стороннего
скрипта, который выполняется на сервере по крону указать что
определення группа файлов в кэше уже не актуальна?
Сторонние скрипты не нужны. Бэкенд в ответе передаёт заголовок
"X-Accel-Key: <md5> <md5> ...". При проверке закэшированного ответа
будут также проверяться время обноволения каждого ключа. Если ответ
старше, чем любой ключ, то запрос уходит к бэкенду. Запросы, которые
могут повлиять на подобные закэшированные ответы, должны содержать
специальное поле с ключом. При получении такого запроса ставится новое
время для данного ключа.
Эти ключи как я понимаю, будут формироваться скриптом. Для меня этот
вариант не подходит, т.к. я хочу макимально избавиться от скриптов. А
так на каждый запрос скрипт будет вызываться. :(
Ключи формируются бэкендом.
Тогда не понял. Бэкенд это апачь. Откуда он будет брать нужные значения
ключей? Кроме того, как он их будет формировать, если при генерации
страници неизвестно когда потребуется ее опять сгенерировать (т.е. когда
обновяться данные)?
Ключи берутся оттуда же, откуда предполагается брать спец.файлы, с помощью
которых проверяется правильность ответов. Ключ можно формировать так же,
как предполагается формировать имена этих файлов.
Эти спец. файлы предполагается генерировать оффлайновыми скриптами, которые
обрабатывают данные (конкретно - добавляют новые данные).
Тогда эти скрипты могут делать простой GET с ключом, чтобы nginx
обновлял время для ключа. На бэкенд запрос можно даже не передавать.
Ключ - это не время
кэширования. Это просто ключ. У него есть время его обновления. А сам ключ
неизменен.
Т.е. фактически это получается типа указания, что в определенное заранее
известное время страницы с привязанными к этому времени ключами должны
потерять актуальность? Все одновременно? В принципе, это устранит проблему
синхронизации данных между страницами большого списка.
Нет, если опредёленное время заранее известно, то бэкенд для всех
таких страниц может выдавать соответствующий X-Accel-Expire.
Ключ нужен для ситуация, когда время устаревания неизвестно, а зависит
от клиентов, пример - форум с закэшированным обсуждением. При постинге
новых данных закэшированные данные нужно обновить.
Так. А может быть тогда получится указать бэкенду динамически что
определенный ключь утратил актуальность и надо сбросить кэшь с данным ключем?
Т.е. то, что предлагал Максим, но оперировать уже не uri, а вот этими твоими
ключами.
Указывать нужно не бэкенду, а nginx'у. Да, можно - простой GET.
Игорь Сысоев
