Пожелание по 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:
>>>>>>>> 
>>>>>>>>> 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 с упоминанием одного из этих 
> ключей, кэши в которых они упомянаются обновяться.
>
> Все верно?

За одним исключением - файлы кэше не обновятся, а будут помечены как
устаревшие. Обновятся они только при запросе.


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