Просто как вариант решения...
Отдельный модуль для nginx для remote clearing cache
С форматом вызова вроде http://nginx.fronend/clear_cache?regex="section=123"
Который бы убирал все закешированые файлы URL которых попадает под
переданный regexp.
Тогда и можно не ограничивать backend/frontend одной машиной
Тогда автор backend может реализовать любой алгоритм сброса cache какой ему
необходимо (если URL навигация нормально структурирована).
Такой поиск будет работать медленно.
-----Original Message-----
From: Sysoev Igor
Sent: Tuesday, March 15, 2005 6:33 PM
To: nginx-ru@xxxxxxxxx
Subject: Re: Пожелание по mod_rewrite
On Tue, 15 Mar 2005, Andrew Velikoredchanin wrote:
Boguk Maxim пишет:
Генератор статического HTML и кеширование с возможностью сб
роса отдельных
документов по инициативе backend почти одно и тоже.
При этом кеширование не генерирует заведомо не используемые
страницы в
отличии от генераторов статического html.
В общем реально надо механизм сброса части кеша по regexp п
о инициативе
backend вот.
(полный сброс не предлагать при обьеме кеша 10Gb+ :))
Мне бы тоже пригодилось.
Ну, скажем, не со стороны бэкэнда, а со стороны вообще. :) К
ак вариант -
введение условий либо в механизм кэша, либо в mod_rewrite.
Кстати, Игорь. Если делать механизм условного кэширования на
основе времени
спец. файла и времени кэша текущего файла, то надо учитывать
что путь к спец.
файлу должен строиться на основе url. Только вот без regexp
думаю, здесь не
обойтись. Т.к. при необходимости введения спец. файла для ка
талогов нужно
иметь возможность указывать не весь url, а с учетом уровня в
ложенности.
Файлы ограничивают использование одной машиной. regex'ы использовать
нереально. Я вижу такое решение: нужно добавлять в заголовок о
твета ключ(и),
от которого зависит кэширование. Запросы, после которых часть ответов
становятся неверными (например, POST'ы), должны передавать так
ой же ключ.
Эти ключи будут храниться в своём кеше.
Игорь Сысоев
http://sysoev.ru