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

[Ивано++]

Может кому-нибудь пригодится...

Попробовал перевести кэширование на memcache

PHP код:


$TYPO3_CONF_VARS['SYS']['useCachingFramework'] = '1';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['backend'] = 't3lib_cache_backend_MemcachedBackend';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['options'] = array(
     'servers' => array('localhost:11211'),
     );
     
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['backend'] = 't3lib_cache_backend_MemcachedBackend';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['options'] = array(
     'servers' => array('localhost:11211'),
     );
     
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['backend'] = 't3lib_cache_backend_MemcachedBackend';
    $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['options'] = array(
     'servers' => array('localhost:11211'),
     );
    
        /*
        
            $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['frontend'] = 't3lib_cache_frontend_VariableFrontend';
            $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['frontend'] = 't3lib_cache_frontend_VariableFrontend';
            $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['frontend'] = 't3lib_cache_frontend_VariableFrontend';
    
        */ 


Теперь таблицы
cf_cache_hash 0
cf_cache_hash_tags 0
cf_cache_pages 0
cf_cache_pages_tags 0
cf_cache_pagesection 0
cf_cache_pagesection_tags 0
cf_extbase_object 0
cf_extbase_object_tags 0
cf_extbase_reflection 0
cf_extbase_reflection_tags
пустые...

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

Кроме того, если мы используем для кэширования memcache (а не БД, и не файлы) - у нас получается "чистый проект" - который не захламляется всяким временным мусором - в качестве исключения конечно можно оставить вопрос с папкой typo3temp - но это очень легко исключается при бэкапе в настройках хостинга (мы исключаем ее из резервного копирования, ровно как и папки t3lib, typo3).

--
Единственное конечно что еще хотелось бы также что бы было это таблицы
cache_extensions
cache_imagesizes
и таблицы realurl.

Если так будет - то на любом проекте можно совершенно спокойно делать копию БД - проекта без всяких извращений и приступать к правкам.

Не знаю кто как делает - но для меня проще сделать дамп бд - 5-10 мб с чистыми данными, чем делать бэкап базы lданных со всем что там есть (1Gb+) или еще каким-то путями вырезать таблицы с помощью сторонних решений. А так зашел в админер и все..

И потом memcache - работает на Facebook... Насколько я понял по статьям из интернета.
И уверен, что тема тэгизации там есть - сейчас ищу и изучаю...
http://ekimoff.ru/329/

Ведь по идее в проекте самое главное это данные (сами записи - новость 1, новость 2) - и исходники, которые эти данные выводят во FE.
И все. А все что временное - это временное. Кэширование как вижу - это лишь способ а) увеличить скорость загрузки FE б) уменьшить/снизить нагрузки на сервер (на любой). И потом еще интересным является вопрос о том, что вот зашли 10-человек на сайт - и первый запустил процесс записи кэша, а остальные - им либо ждать пока запишется кэш, либо как?

[dmartynenko]

Тоже пока используем memcached. Тэгизации там точно нет. Делали как-то отдельные патчи и форки сторонние разработчики, но до сих пор в основную ветку тэги не попали. А потом все переключили внимание на NoSQL, и memcached стабильной, но неразвивающейся технологией (v1.4.15, release notes 2012-9-3).

Если верить http://wiki.typo3.org/Caching_framework, то предпочтительно использовать Redis. Который во многом схож с memcached, но не удаляет данные из ОЗУ при ее нехватке, а пишет на диск.

http://wiki.typo3.org/Caching_framew...mcachedBackend

Warning and design constraints

Memcached is by design a simple key-value store. Values must be strings and there is no relation between keys. Since the caching framework needs to structure it to store the identifier-data-tags relations, for each cache entry it stores an identifier->data, identifier->tags and a tag->identifiers entry.

This leads to structural problems:
If memcache runs out of memory but must store new entries, it will toss *some* other entry out of the cache (this is called an eviction in memcached speak).
If data is shared over multiple memcache servers and some server fails, key/value pairs on this system will just vanish from cache.

http://wiki.typo3.org/Caching_framew...d_RedisBackend

t3lib_cache_backend_RedisBackend

Redis is a key-value storage/database. In contrast to memcached, it allows structured values. Data is stored in RAM but it allows persistence to disk and doesn't suffer from the design problems which exist with the memcached backend implementation. The redis backend can be used as an alternative of the database backend for big cache tables and helps to reduce load on database servers this way. The implementation can handle millions of cache entries each with hundreds of tags if the underlying server has enough memory.

Но сами редиску не пробовали, по привычке везде memcached.

[Ивано++]

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

Тоже пока используем memcached. Тэгизации там точно нет.

Тоже решил остановиться на memcache.

Про тэгизацию все таки поищу...
Думаю что есть алгоритмы - за столько лет существования этого memcache.

[dmartynenko]

Алгоритмы то есть, и описаны (я недавно постил ссылки на пару). Только все они требуют вместо одного запроса делать много на каждую операцию. А это ведет с уменьшению полезности memcached.

В дополнение к этому, и это пишут как минус в http://wiki.typo3.org/Caching_framework, тэги и данные могут быть удалены memcached произвольно и независимо друг от друга. Ведь memcached это такая штука, которая ничего никому не гарантирует "by design".

[Ивано++]

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

http://wiki.typo3.org/Caching_framework, -.

вот этот Caching_framework - по умолчанию он пишется на Бд.
Можно очисть кэш конкретной страницы по ID-страницы.
А вот очистить кэш расширения, сгенерированного через useCacheHash - уже не получится...

Но думаю, что здесь все равно с тэгами особо большоего смысла углублятся в "извращения" нет.... Не знаю на сколько сложная логика кэширования реализована на typo3.org - но думаю там все предельно просто, добавил - сбросил. А где то наверное и вовсе Не кэшируется. И все работает! При БД в 70Gb и посещаемостью наверно достаточной.

[dmartynenko]

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

[Ивано++]

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

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

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

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

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

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

[dmartynenko]

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

Если так будет - то на любом проекте можно совершенно спокойно делать копию БД - проекта без всяких извращений и приступать к правкам.[/color][/b]

Я постил недавно простенький SSH скрипт (можно переписать на PHP), который дампит все таблицы с данными, а для всяких кэшей - только структуру. Чуть сложней тупого дампа базы, но зато заметно удобней.

Таблицы realurl вряд ли можно вынести в memcached. Во первых в memcached не структурированные данные, и возможно realurl по разным полям поиск делает. Во вторых, у нас на одном проекте до 2 гигов таблицы realurl занимают. Сильно жирно столько памяти на один realurl выделять

[Ивано++]

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

Я постил недавно простенький SSH скрипт (можно переписать на PHP), который дампит все таблицы с данными, а для всяких кэшей - только структуру. Чуть сложней тупого дампа базы, но зато заметно удобней.

Есть такое расширение "truncate_tables" - суть его в том, что там где сброс кэшей - появляется новая молния. При нажатии на нее очищается список указанных таблиц. Я немного модифицировал его в одном из расшриений - и он у меня чистит все таблицы, которые содержат *cache*, А также sys_log и другие которые содержат временные данные.

Можно сделать "еще одну молнию на основе этого SSH->PHP скрипта" - при нажатии на нее будет создаваться бэк ап БД сайта и ложится в папку fileadmin/__temp__/ - но пока не знаю на сколько это нужно? Либо еще круче - нажал на кнопку и получил бэкап БД. Просто я обычно делаю дамп БД через Админер - после нажатия на синию молнию (ну восстановятся кэши потом - не 100 раз же на дню я ее нажимаю синуюю молнию) - получаю чистую БД без кэшей...

--
Просто все таки стремлюсь сделать саму БД - чистой.
Вот как таблица excel - мы же пишем там только нужные данные, а весь старый мусор бросаем в корзину...

[Ивано++]

В общем по тэгам - тогда посмотрю и напишу в эту тему.