Всетаки - кэширование с использованием БД - это очень не удобно!

[dmartynenko]

Так вы же не знаете что там за железо. Может там отказоустойчивый кластер из 50 серверов: 10 на БД, 10 на статику, 20 на фронтенд и 5 на бэкенд, и 5 еще на какую-нибудь хрень

[Ивано++]

Сообщение от dmartynenko

Так вы же не знаете что там за железо. Может там отказоустойчивый кластер из 50 серверов: 10 на БД, 10 на статику, 20 на фронтенд и 5 на бэкенд, и 5 еще на какую-нибудь хрень

Ну главное же что работает...
Вот с тэгами сейчас разбираюсь и посмотрю есть ли смысл заморачиватьс по схеме...

При добавлении новости:

1. сбросить карту сайта sitemap.xml
2. сбросить карту сайта - страницу
3. сбросить главную
4. сбросить баннеры (последние новости)
5. сбросить постраничную навигацию
6. сбросить комментарии к новости
--
x. и т.д

может и нет особо большого смысла так по тегам заморачиваться... а лучше вкладываться в железо... - для которого есть кэш, нету кэша - как то особо разницы нет - добавил новость и спбросил "Все разом" - хотя на моей практике был один такой человек с которым сталкивался и он хихикнул - "А что добавли и весь кэш сбрасывать??". Но без кэша думаю что на любом железе не актуально.

[Ивано++]

Ну пока из наблюдений - что мне показалось в отличие от файлов - это то что запись в memcache - как-то быстрее происходит....

[dmartynenko]

Как раз "при добавлении" - это самый хитрый момент в чистке кэшей.

Обычно как: вывели список новостей, закэшировали, в качестве тэгов использовали id-шники новостей. Соответственно при изменении или удалении (скрытии) новости одновременно сбрасываем кэши по "тэгу id-шнику".

А новая новость еще ни с какими кэшами-тэгами не связана! Так что сбрасывать?

PS: На тестовой машине, когда кэшей мало считывание из файла и из memcached, ИМХО, может быть одинаковым по времени. Так как обращение к файлам ОС + ФС кэширует в памяти, и получается по сути то же самое. А вот в реальной жизни, когда кэшей много, всю ФС в память не поместишь и разница будет.

[Ивано++]

Сообщение от dmartynenko

Как раз "при добавлении" - это самый хитрый момент в чистке кэшей.

Обычно как: вывели список новостей, закэшировали, в качестве тэгов использовали id-шники новостей. Соответственно при изменении или удалении (скрытии) новости одновременно сбрасываем кэши по "тэгу id-шнику".

А новая новость еще ни с какими кэшами-тэгами не связана! Так что сбрасывать?

PS: На тестовой машине, когда кэшей мало считывание из файла и из memcached, ИМХО, может быть одинаковым по времени. Так как обращение к файлам ОС + ФС кэширует в памяти, и получается по сути то же самое. А вот в реальной жизни, когда кэшей много, всю ФС в память не поместишь и разница будет.

В общем сейчас прихожу к выводу - кэшируется на БД realurl - и ладно...
В этом нет ничего плохого...
С memcache - конечно лучше стало (имею в виду, то что удалось поставить на memcache)... И это заметно даже на не большой проекте.

Единственное проблема с которой столкнулся при использовании memcache - это на основе чего генерировать уникальный ключ кэша - что бы разрешить запись кэша?

На основе id-страницы - не подходит
На основе useCacheHash - также не подходит

В обоих случаях пользователь может ввести id=xxxx - и будет создан кэш + 1...
И таким образом будет насоздано куча всяких "несущесвующих" кэшей.

А с тэгами ищу решение...

[Ивано++]

Сообщение от Ивано++

В общем сейчас прихожу к выводу - кэшируется на БД realurl - и ладно...
В этом нет ничего плохого...
С memcache - конечно лучше стало (имею в виду, то что удалось поставить на memcache)... И это заметно даже на не большой проекте.

Единственное проблема с которой столкнулся при использовании memcache - это на основе чего генерировать уникальный ключ кэша - что бы разрешить запись кэша?

На основе id-страницы - не подходит
На основе useCacheHash - также не подходит

В обоих случаях пользователь может ввести id=xxxx - и будет создан кэш + 1...
И таким образом будет насоздано куча всяких "несущесвующих" кэшей.

А с тэгами ищу решение...

--- С генерацией ключа - так и не разобрался...
Ищу тэги для memcache...

[dmartynenko]

В общем случае ключ в кэше должен учитывать все что у вас может повлиять на содержимое. Т.е. id страницы, текущий type, GET переменные, содержимое config и т.п. И еще место откуда вызывается.

Примерно так

PHP код:

            $cache_key = md5(serialize(array(
                __CLASS__, __FUNCTION__,
                $GLOBALS["TSFE"]->id, $GLOBALS["TSFE"]->type,
                $_GET[...]))); 


Нужно помнить еще и такой нюанс - если у вас на одном сервере несколько проектов, и есть одни и те же модули. То теоритически разные клиенты могут использовать одинаковые ключи. Ведь в мемкешед общее пространство, никак не разграниченное между разными пользователями и подключениями.

[Ивано++]

Сообщение от dmartynenko

В общем случае ключ в кэше должен учитывать все что у вас может повлиять на содержимое. Т.е. id страницы, текущий type, GET переменные, содержимое config и т.п. И еще место откуда вызывается.

Примерно так

PHP код:

            $cache_key = md5(serialize(array(
                __CLASS__, __FUNCTION__,
                $GLOBALS["TSFE"]->id, $GLOBALS["TSFE"]->type,
                $_GET[...]))); 


Нужно помнить еще и такой нюанс - если у вас на одном сервере несколько проектов, и есть одни и те же модули. То теоритически разные клиенты могут использовать одинаковые ключи. Ведь в мемкешед общее пространство, никак не разграниченное между разными пользователями и подключениями.

Из всего этого не понятно следующее:

1. вот человек ввел id=5005034 (у нас движок выдаст 404 - ошибку) - сам просчитает, т.к. такой страницы нет, и для type - тоже самое
а вот если мы используем показ новостей к примеру по additionalparams для typolink - пример tx_news[id]=50
получается если человек от "себя" введет не верный id-записи, то у Вас запишется кэш +1 - которого в принципе не существует. И так до тех пор, пока он (злоумышленник-вредитель) не устанет вводить разные значения - одним словом так и сайт можно "завалить".... Получается как - каждый раз проверять на существоание такого ID, и если есть, то разрешаем писать кэш?

Как проверить валидность id-записи?

2. вот мое наблюдение по работе ядра системы:
если у нас запрашивается не верная страница по id, type - то typo3 в кэш ничего не пишет - здесь вродебы все ясно...
но вот как она проверяет additionalparams, в т.ч. useCachHash - что это валидный url? Как я не старался - все равно она лишних кэшей никаких не пишет... Даже useCachHash = FALSE

Сообщение от dmartynenko

Нужно помнить еще и такой нюанс - если у вас на одном сервере несколько проектов, и есть одни и те же модули. То теоритически разные клиенты могут использовать одинаковые ключи. Ведь в мемкешед общее пространство, никак не разграниченное между разными пользователями и подключениями.

А про это, думаю - что просто префикс добавить и все...