Пожелание по mod_rewrite

[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:
>>>>>> 
>>>>>>> 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.


Игорь Сысоев
http://sysoev.ru