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

[Andrew Velikoredchanin]

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.

Во! Вот теперь понял.

Т.е. при выдаче страницы с бэкэнда генерирую два ключа. Один уникальный 
для страницы, другой для группы, к которой эта страница принадлежит (я 
так думаю, что к-во ключей по возможности лучше не ограничивать или 
ограничит 4-мя или 8-ю - это уж смотри сам).

Потом, когда я дам специальную команду nginx с упоминанием одного из 
этих ключей, кэши в которых они упомянаются обновяться.

Все верно?

Если так - это отличный вариант. Тогда отпадает необходимость в каких-то 
дополнительных файлах, все получится достаточно естественно. :) В общем, 
ждемс. :)