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

Andrew Velikoredchanin andrew at rodtext.ru
Tue Mar 15 20:33:52 MSK 2005


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

Эти ключи как я понимаю, будут формироваться скриптом. Для меня этот 
вариант не подходит, т.к. я хочу макимально избавиться от скриптов. А 
так на каждый запрос скрипт будет вызываться. :(





More information about the nginx-ru mailing list