Просмотр полной версии : Всетаки - кэширование с использованием БД - это очень не удобно!
Получается, что бы сделать рез.копию хостинга...
Надо проходится по таблицам...
Да и потом - БД - ведь по идее созданы для полезного контента - а не для мусора (временного)...
Это все равно что я бы в Ecxel таблицах в каждый из своих документов с отчетностью вставлял бы жопу павлина...
Просто так... Кусочек мусора...
Если бы все кэширование проходило и сохронялось в папке typo3temp - да и вообще весь мусор, все временное - что можно бы ло бы удалить - было бы гораздо лучше...
Будем искать расширения на данную тему...
Они есть - но как то сложно ставятся...
Гораздо удобнее так делать копию хостинрга
Да и БД - т.к. они не будут весить по 1 ГБ и более.
Андрей Аксенов
31.05.2013, 12:06
Ну есть в Планировщике задачи по уборке мусора... Можно это делать и в ручную. Во вторых, я не пользуюсь встроенным поиском - может и стоит попробовать новый, но как-то руки не доходят, легче поставить сторонний гугль или яндекс.
Ну а сам механизм INNO в DB подразумевает "раздувание" файлов. Одно спасение - периодическое воссоздание базы данных.
Ну а кеширование во временных файлах довольно широко используется...
Ну есть в Планировщике задачи по уборке мусора... Можно это делать и в ручную.
Это всеравно не удобно...
БД - должна быть для полезного контента - а не для мусора - по крайней мере я к такому выводу прихожу... Читая статьи про кэширование - почему typo3 - выбрала по умолчанию именно этот вариант, а не на файла - так и не понял аргументов...
Во вторых, я не пользуюсь встроенным поиском - может и стоит попробовать новый, но как-то руки не доходят, легче поставить сторонний гугль или яндекс.
Согласен и тоже не использую - хотя бы потому - что это мусор...
А если нужен действительно хороший поиск - то ручками.
Ну а сам механизм INNO в DB подразумевает "раздувание" файлов. Одно спасение - периодическое воссоздание базы данных.
Ну а кеширование во временных файлах довольно широко используется...
Вот в этом то и проблема...
Зачастую народ херачит БД - прямо как есть - 50 мб. - 100 мб. А потом и больше ... И поробуй это все потом восстанови перенеси - начинаются всякие ограничение на время работы, заливки всяких дамперов и прочеее...
Хотя если взять к примеру самый простой сайт моего студ.совета -
studsovet-life.ru - здесь чистый вес БД - всего 2мб....
А если есть хостинг - где висят 5-7 проектов typo3 - то уже очень большая проблема делать рез.копию всего этого дела...
Мне каждый раз приходится протыркивать каждую Бд...
А так, я бы мог сделать общую копию БД - и она бы весила МБ - 20-30...
--
В общем - в будующем буду уходить от этого бреда - когда кэш пишется в БД...
Т.к. ЭТО ДЕЙСТВИТЕЛЬНО БРЕД.
Андрей Аксенов
31.05.2013, 12:44
Согласен... При установке нового ядра иногда приходится и папку с темпами удалять, да и не только при этом, но и зачастую при разработке непонятки бывают. А так - права на папку для временных файлов поставил, и не нужно кеш чистить - запись запрещена :)
Согласен... При установке нового ядра иногда приходится и папку с темпами удалять, да и не только при этом, но и зачастую при разработке непонятки бывают. А так - права на папку для временных файлов поставил, и не нужно кеш чистить - запись запрещена :)
Просто думаю - если на нее поставить права "Запрет" - то будет плохо...
Туда же все пишется все ...
и css и js - и спрайты - одним словом все...
+ картинки, которые создаются как временные "Тип контента изображение" -- все туда...
В общем поищем решение - после отпишемся...
ЖОПА - ЖОпа... эти кэши в БД...
Андрей Аксенов
31.05.2013, 13:33
Да это я вроде как "пошутил", запрета ставить нельзя, так как при этом ошибки появляются - невозможно записать какой-то файл... Это я по аналогии с мультишопом - там как раз кеширование в файлы используется, ну и при изменении данных иногда чистить кеши приходится - ну вот запрет на запись помогает...
-=UncleByte=-
31.05.2013, 13:53
Для кеширование в базе есть серьезные основания:
1. Сайт может функционировать на одном сервере, а БД быть на другом
2. На нагруженных сервера с большим объемом памяти можно вывести всю базу в оперативку и тогда отклик будет существенно быстрее, чем при работе с файлами
Для кеширование в базе есть серьезные основания:
1. Сайт может функционировать на одном сервере, а БД быть на другом
И в чем здесь подоплека?...
2. На нагруженных сервера с большим объемом памяти можно вывести всю базу в оперативку и тогда отклик будет существенно быстрее, чем при работе с файлами
Думаю - здесь только пробовать...
На сайте typo3 - тоже про это говорится...
В общем второй вопрос - это очень сомнительный вопрос о том что лучше...
Для меня пока в любом случае лучше файлы (по крайней мере для сайтов из 10-250 страниц это уж точно!)
НИгде нет однозначного ответа о том, что лучше...
http://alexvolkov.ru/bd-bystree-fajjlov.html
http://hashcode.ru/questions/28006/php-%D1%87%D1%82%D0%BE-%D0%B1%D1%8B%D1%81%D1%82%D1%80%D0%B5%D0%B5-sql-%D0%B8%D0%BB%D0%B8-%D1%84%D0%B0%D0%B9%D0%BB ( сразу первый ответ - (
http://habrahabr.ru/qa/26867/
В общем-то проблема в том, что я делая рез.копии несколькох проетков - 1 хостинг - получаю по сущетству содержимое + мусор - и это уже достало...
//
Вот что еще пищут на хабре.
Кстати, файловая система — это тоже в некотором роде база данных.
-=UncleByte=-
31.05.2013, 15:51
Ну подоплека в том, что могут быть ограничения по доступному дисковому пространству, могуть ограничения по количеству файлов - ограничения могут быть какие угодно.
Для бэкапов без мусора достаточно использовать sypex dumper - можно отметить содержимое каких таблиц не включать в дамп и все.
dmartynenko
05.06.2013, 16:45
Для кеширование в базе есть серьезные основания:
1. Сайт может функционировать на одном сервере, а БД быть на другом
А ведь суть кэша как раз в том, что бы максимально приблизить данные к потребителю. Канал/время отклика по сети к другому серверу чаще всего медленней чем к локальному диску (особенно если он SSD).
2. На нагруженных сервера с большим объемом памяти можно вывести всю базу в оперативку и тогда отклик будет существенно быстрее, чем при работе с файлами
Тут есть нюанс. Таблицы типа MEMORY для кэшей сделать нельзя, так как там в ней нет типов данных BLOB и т.п., а VARCHAR(xxx) разворачиается в фиксированный CHAR(xxx) с соответствующим потреблением памяти.
Второй вариант - размещать сами базы на RAM-диске. А это весьма стремно - при перезагрузке теряются и базы и структуры и подключение их к MySQL
Так что при наличии большого объема памяти кэшировать лучше либо
в файлы на RAM-диск, либо на решения вроде memcached/redis.
-=UncleByte=-
05.06.2013, 17:05
А ведь суть кэша как раз в том, что бы максимально приблизить данные к потребителю. Канал/время отклика по сети к другому серверу чаще всего медленней чем к локальному диску (особенно если он SSD).У большинства отечественных хостеров собственно хостинг и сервер БД разнесены по разным серверам.
Тут есть нюанс. Таблицы типа MEMORY для кэшей сделать нельзя, так как там в ней нет типов данных BLOB и т.п., а VARCHAR(xxx) разворачиается в фиксированный CHAR(xxx) с соответствующим потреблением памяти.
Второй вариант - размещать сами базы на RAM-диске. А это весьма стремно - при перезагрузке теряются и базы и структуры и подключение их к MySQL
Так что при наличии большого объема памяти кэшировать лучше либо
в файлы на RAM-диск, либо на решения вроде memcached/redis.
Я как раз и писал что при большом доступном количестве памяти проще всего вынести БД в эту самую память и таким образом и снизить время доступа к данным.
Эээээ...
Не думал, что когда нибудь такое скажу... НО мне даже очень понравилось кэширвоание на основе БД....:):):)
Как ни будь расскажу почему (единственный минус конечно когда на хостингах жмешь кнопку рез. копии, то база вся дампится)...
Даже smarty - кэш переведу на БД (с такой возможностью)...
dmartynenko
02.07.2013, 13:11
Вы лучше напишите "почему". Обещали :)
От себя приведу такой пример. На одном сайте в таблице RealURL encode cache больше миллиона записей, в decode cache раза в два меньше. По статистике запросы на выборку из этой таблицы по Primary Key регулярно пишуться в лог относительно медленных запросов (наряду с выборками из tt_news), для этого в t3lib_db добавлен небольшой код.
Любая операция со страницей в BE (иногда приходится делать на рабочем сайте) ведет к операции DELETE FROM ... WHERE pid = xx
Если делать таблицу MyISAM, то под нагрузкой такая операция практически вешает сервер на 3-7 минут. Если делать InnoDB (как того рекомендует автор Дмитрий Дулепов) то якобы операция удаления не должна блокировать таблицу и все должно продолжать работать. На практике серверу еще хуже. Так как пока очень долго идет операция удаления (десятки минут), то все другие операции с таблицей очень сильно замедляются и LA сервера растет и растет. Даже если вручную снять этот висящий запрос на удаление, то еще пару десятков минут продолжает висеть в списке процессов MySQL некая операция "freeing items" и тоже все тормозит.
Так что пока вы кешируете в таблицы что-то небольшое и немного - это удобно. Но в реальной жизни на крупных сайтах все не так радужно.
Мне нравиться Redis - с одной стороны использует память как и memcached, с другой данные уже не влезающие в память пишутся на диск, а не просто удаляются.
Конечно в Redis и в memcached единственная проблема которая не так красиво решается как в СУБД - это тэгирование записей кэша. Ну я тут не стал выдумывать очередной велосипед и храню пары ключ-тэг в MySQL.MEMORY таблице. Когда-то видел сравнение скорости работы memcached vs MEMORY таблиц, получилось примерно одинаково.
Вы лучше напишите "почему". Обещали
1) С точки зрения управления кэшированием на основе БД - можно сделать более сложную логику - в виде "матрешки". Где кроме того, можно еще и по определенным тэгам удалять отдельные кэши.
К примеру у нас есть новости на сайте:
Они выводятся в
новостях (список новостей с потраничной навигации)
сама новость
новость в карте сайта
блок последних новостей на главной странице
блок новости в слайдере на всех страницах...
кроме того, может быть в sitemap...
Мы можем по определенным тэгам сбросить все это при изменении/добавлении новости - и нет необходимости сбрасывать кэш всего сайта - но это очень актуально на больших и посещяемых проектах...
Хотя все таки думаю - что даже это все дело потянет хороший хостинг...
Подобную матрешку - пробовал реализовать на файлах...
Но, к сожалению, очень не гибко в сравнении с Файлами.
2) С точки зрения записи файлов на кэшах - не знаю почему - но мне показалось что это работает по скорость также как и на БД, а вот с позции манипуляций кэшем на файлах - как-то дольше - в т.ч. удаление.:rolleyes:
А с точки зрения минусов - есть один минус, который по прежнему к сожалению вижу...
Таблицы кэширования лучше всего переводить в отдельную БД... Т.е. специально для кэшей держать отдельную БД...
А то при бэкапах хостинга обычно он бэкапит все в одну кучу...
А так было бы
1. Дамп Контента
2. Дамп Кэша (только структура)
3. FTP
dmartynenko
03.09.2013, 13:58
Так вы не внимательно читаете, что я предлагаю выше.
Да, работать с тэгами в БД удобней всего.
В файловом кэше их попросту не сделать. В memcached и т.п. вариациях тоже нет встроенных средств для работы с тэгами, надо все равно делать свою логику.
Но! Писать BLOB данные в MySQL в большом количестве - это самый плохой вариант использования БД. Никаких преимуществ, одни недостатки.
Поэтому, ИМХО, самый лучший вариант - хранить сами данные по ключу в файлах, memcached, redis (кому что нравиться и на что хватает ОЗУ). А вот связь тэги-ключ хранить в БД. Так как именно для этого реляционные БД предназначены - SELECT key FROM key_tags WHERE tag = "abc" и т.п.
Плюс табличка key_tags компактна, длинна строк у нее фиксированная и можно заранее просчитать ее максимальный размер. Что позволяет делать ее типа MEMORY. А значит по скорости она будет близка к скорости memcached.
Конечно это чуть более сложная логика в PHP. Но все равно проще варианта, когда организуют хранение тэгов в memcached (http://dklab.ru/lib/Dklab_Cache/, http://www.smira.ru/posts/20081029web-caching-memcached-5.html)
Так вы не внимательно читаете, что я предлагаю выше.
Да, работать с тэгами в БД удобней всего.
В файловом кэше их попросту не сделать. В memcached и т.п. вариациях тоже нет встроенных средств для работы с тэгами, надо все равно делать свою логику.
Но! Писать BLOB данные в MySQL в большом количестве - это самый плохой вариант использования БД. Никаких преимуществ, одни недостатки.
Поэтому, ИМХО, самый лучший вариант - хранить сами данные по ключу в файлах, memcached, redis (кому что нравиться и на что хватает ОЗУ). А вот связь тэги-ключ хранить в БД. Так как именно для этого реляционные БД предназначены - SELECT key FROM key_tags WHERE tag = "abc" и т.п.
Плюс табличка key_tags компактна, длинна строк у нее фиксированная и можно заранее просчитать ее максимальный размер. Что позволяет делать ее типа MEMORY. А значит по скорости она будет близка к скорости memcached.
Конечно это чуть более сложная логика в PHP. Но все равно проще варианта, когда организуют хранение тэгов в memcached (http://dklab.ru/lib/Dklab_Cache/, http://www.smira.ru/posts/20081029web-caching-memcached-5.html)
В общем тогда пока ничего сказать по этому вопросу не могу...
Здесь нужно "собирать опыт" :)
Только одно - memcached - для меня не удобно...
Может кому-нибудь пригодится...
Попробовал перевести кэширование на memcache
$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
26.09.2013, 18:41
Тоже пока используем memcached. Тэгизации там точно нет. Делали как-то отдельные патчи и форки сторонние разработчики, но до сих пор в основную ветку тэги не попали. А потом все переключили внимание на NoSQL, и memcached стабильной, но неразвивающейся технологией (v1.4.15, release notes 2012-9-3).
Если верить http://wiki.typo3.org/Caching_framework, то предпочтительно использовать Redis. Который во многом схож с memcached, но не удаляет данные из ОЗУ при ее нехватке, а пишет на диск.
http://wiki.typo3.org/Caching_framework#t3lib_cache_backend_MemcachedBac kend
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_framework#t3lib_cache_backend_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.
Тоже пока используем memcached. Тэгизации там точно нет.
Тоже решил остановиться на memcache.
Про тэгизацию все таки поищу...
Думаю что есть алгоритмы - за столько лет существования этого memcache.:)
dmartynenko
26.09.2013, 18:53
Если так будет - то на любом проекте можно совершенно спокойно делать копию БД - проекта без всяких извращений и приступать к правкам.[/COLOR][/B]
Я постил недавно простенький SSH скрипт (можно переписать на PHP), который дампит все таблицы с данными, а для всяких кэшей - только структуру. Чуть сложней тупого дампа базы, но зато заметно удобней.
Таблицы realurl вряд ли можно вынести в memcached. Во первых в memcached не структурированные данные, и возможно realurl по разным полям поиск делает. Во вторых, у нас на одном проекте до 2 гигов таблицы realurl занимают. Сильно жирно столько памяти на один realurl выделять :)
dmartynenko
26.09.2013, 19:05
Алгоритмы то есть, и описаны (я недавно постил ссылки на пару). Только все они требуют вместо одного запроса делать много на каждую операцию. А это ведет с уменьшению полезности memcached.
В дополнение к этому, и это пишут как минус в http://wiki.typo3.org/Caching_framework, тэги и данные могут быть удалены memcached произвольно и независимо друг от друга. Ведь memcached это такая штука, которая ничего никому не гарантирует "by design".
Я постил недавно простенький SSH скрипт (можно переписать на PHP), который дампит все таблицы с данными, а для всяких кэшей - только структуру. Чуть сложней тупого дампа базы, но зато заметно удобней.
Есть такое расширение "truncate_tables" - суть его в том, что там где сброс кэшей - появляется новая молния. При нажатии на нее очищается список указанных таблиц. Я немного модифицировал его в одном из расшриений - и он у меня чистит все таблицы, которые содержат *cache*, А также sys_log и другие которые содержат временные данные.
Можно сделать "еще одну молнию на основе этого SSH->PHP скрипта" - при нажатии на нее будет создаваться бэк ап БД сайта и ложится в папку fileadmin/__temp__/ - но пока не знаю на сколько это нужно? Либо еще круче - нажал на кнопку и получил бэкап БД. Просто я обычно делаю дамп БД через Админер - после нажатия на синию молнию (ну восстановятся кэши потом - не 100 раз же на дню я ее нажимаю синуюю молнию) - получаю чистую БД без кэшей...
--
Просто все таки стремлюсь сделать саму БД - чистой.
Вот как таблица excel - мы же пишем там только нужные данные, а весь старый мусор бросаем в корзину...
В общем по тэгам - тогда посмотрю и напишу в эту тему.:o
http://wiki.typo3.org/Caching_framework, -.
вот этот Caching_framework - по умолчанию он пишется на Бд.
Можно очисть кэш конкретной страницы по ID-страницы.
А вот очистить кэш расширения, сгенерированного через useCacheHash - уже не получится...
Но думаю, что здесь все равно с тэгами особо большоего смысла углублятся в "извращения" нет.... Не знаю на сколько сложная логика кэширования реализована на typo3.org - но думаю там все предельно просто, добавил - сбросил. А где то наверное и вовсе Не кэшируется. И все работает! При БД в 70Gb и посещаемостью наверно достаточной.
dmartynenko
26.09.2013, 20:27
Так вы же не знаете что там за железо. Может там отказоустойчивый кластер из 50 серверов: 10 на БД, 10 на статику, 20 на фронтенд и 5 на бэкенд, и 5 еще на какую-нибудь хрень :)
Так вы же не знаете что там за железо. Может там отказоустойчивый кластер из 50 серверов: 10 на БД, 10 на статику, 20 на фронтенд и 5 на бэкенд, и 5 еще на какую-нибудь хрень :)
Ну главное же что работает...:)
Вот с тэгами сейчас разбираюсь и посмотрю есть ли смысл заморачиватьс по схеме...
При добавлении новости:
1. сбросить карту сайта sitemap.xml
2. сбросить карту сайта - страницу
3. сбросить главную
4. сбросить баннеры (последние новости)
5. сбросить постраничную навигацию
6. сбросить комментарии к новости
--
x. и т.д
может и нет особо большого смысла так по тегам заморачиваться... а лучше вкладываться в железо... - для которого есть кэш, нету кэша - как то особо разницы нет - добавил новость и спбросил "Все разом" - хотя на моей практике был один такой человек с которым сталкивался и он хихикнул - "А что добавли и весь кэш сбрасывать??". Но без кэша думаю что на любом железе не актуально.
Ну пока из наблюдений - что мне показалось в отличие от файлов - это то что запись в memcache - как-то быстрее происходит....:)
dmartynenko
27.09.2013, 15:40
Как раз "при добавлении" - это самый хитрый момент в чистке кэшей.
Обычно как: вывели список новостей, закэшировали, в качестве тэгов использовали id-шники новостей. Соответственно при изменении или удалении (скрытии) новости одновременно сбрасываем кэши по "тэгу id-шнику".
А новая новость еще ни с какими кэшами-тэгами не связана! Так что сбрасывать?
PS: На тестовой машине, когда кэшей мало считывание из файла и из memcached, ИМХО, может быть одинаковым по времени. Так как обращение к файлам ОС + ФС кэширует в памяти, и получается по сути то же самое. А вот в реальной жизни, когда кэшей много, всю ФС в память не поместишь и разница будет.
Как раз "при добавлении" - это самый хитрый момент в чистке кэшей.
Обычно как: вывели список новостей, закэшировали, в качестве тэгов использовали id-шники новостей. Соответственно при изменении или удалении (скрытии) новости одновременно сбрасываем кэши по "тэгу id-шнику".
А новая новость еще ни с какими кэшами-тэгами не связана! Так что сбрасывать?
PS: На тестовой машине, когда кэшей мало считывание из файла и из memcached, ИМХО, может быть одинаковым по времени. Так как обращение к файлам ОС + ФС кэширует в памяти, и получается по сути то же самое. А вот в реальной жизни, когда кэшей много, всю ФС в память не поместишь и разница будет.
В общем сейчас прихожу к выводу - кэшируется на БД realurl - и ладно...
В этом нет ничего плохого...
С memcache - конечно лучше стало (имею в виду, то что удалось поставить на memcache)... И это заметно даже на не большой проекте.
Единственное проблема с которой столкнулся при использовании memcache - это на основе чего генерировать уникальный ключ кэша - что бы разрешить запись кэша?
На основе id-страницы - не подходит
На основе useCacheHash - также не подходит
В обоих случаях пользователь может ввести id=xxxx - и будет создан кэш + 1...
И таким образом будет насоздано куча всяких "несущесвующих" кэшей.
А с тэгами ищу решение...
В общем сейчас прихожу к выводу - кэшируется на БД realurl - и ладно...
В этом нет ничего плохого...
С memcache - конечно лучше стало (имею в виду, то что удалось поставить на memcache)... И это заметно даже на не большой проекте.
Единственное проблема с которой столкнулся при использовании memcache - это на основе чего генерировать уникальный ключ кэша - что бы разрешить запись кэша?
На основе id-страницы - не подходит
На основе useCacheHash - также не подходит
В обоих случаях пользователь может ввести id=xxxx - и будет создан кэш + 1...
И таким образом будет насоздано куча всяких "несущесвующих" кэшей.
А с тэгами ищу решение...
--- С генерацией ключа - так и не разобрался...
Ищу тэги для memcache...:cool:
dmartynenko
01.10.2013, 15:33
В общем случае ключ в кэше должен учитывать все что у вас может повлиять на содержимое. Т.е. id страницы, текущий type, GET переменные, содержимое config и т.п. И еще место откуда вызывается.
Примерно так
$cache_key = md5(serialize(array(
__CLASS__, __FUNCTION__,
$GLOBALS["TSFE"]->id, $GLOBALS["TSFE"]->type,
$_GET[...])));
Нужно помнить еще и такой нюанс - если у вас на одном сервере несколько проектов, и есть одни и те же модули. То теоритически разные клиенты могут использовать одинаковые ключи. Ведь в мемкешед общее пространство, никак не разграниченное между разными пользователями и подключениями.
В общем случае ключ в кэше должен учитывать все что у вас может повлиять на содержимое. Т.е. id страницы, текущий type, GET переменные, содержимое config и т.п. И еще место откуда вызывается.
Примерно так
$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
01.10.2013, 18:58
С левыми id проблем не вижу.
Вы же делаете как:
1. Строите cache_key
2. Проверяете в кэше
3. Если нет, то делаете запрос в БД
4. Если нет записи - выдаете 404
5. Если есть в БД, формируете контент и пишете в кэш
Логично что ответы 404 в кэш писать не нужно.
А про это, думаю - что просто префикс добавить и все...
Это я к тому, что бы не использовать тривиальные ключи вроде table_name+id, или просто id. Если добавить к ключу $GLOBALS["TSFE"]->id, а еще можно и domain, то уникальность между сайтами гарантирована.
С левыми id проблем не вижу.
Вы же делаете как:
1. Строите cache_key
2. Проверяете в кэше
3. Если нет, то делаете запрос в БД
4. Если нет записи - выдаете 404
5. Если есть в БД, формируете контент и пишете в кэш
Логично что ответы 404 в кэш писать не нужно.
К сожалению - это очень сложный механизм...
Возможно нашел решение - более простое - по поводу разрешить/запретить кэширование - но оно связанно с useCashHash - и не знаю насколько оно будет уместно ... И сейчас не совсем пойму - почему useCashHash так плох?
Это я к тому, что бы не использовать тривиальные ключи вроде table_name+id, или просто id. Если добавить к ключу $GLOBALS["TSFE"]->id, а еще можно и domain, то уникальность между сайтами гарантирована.
Может это замечательная функция позволит уж точно не запутаться на разных проектах:
md5(t3lib_div::getIndpEnv('TYPO3_SITE_URL') ... // текущий url-страницы ?
Это то, что так долго искал - наверное не 1-и месяц:
самое странное что в тему useCashHash valid - на оффициальном форуме typo3.org - мне ничего не ответили, вернее ответили, но как-то расплывчато было сказано - что это не возможно - и это ответ от Core...!!!... Странно что там, даже PHP-код вставить нет возможности....
Теперь из t3lib_div::cHashParams и t3lib_div::calculateCHash стало понятно, как можно проверить ... useCashHash - оказывается - это просто md5 - всех _GET-параметров....
//////////////////////////////////////////////////////////////////////
// Определяем тип страницы
//////////////////////////////////////////////////////////////////////
$cHash_array = t3lib_div::cHashParams( t3lib_div::implodeArrayForUrl('', $GLOBALS['_GET']) );
$cHash_calc = t3lib_div::calculateCHash($cHash_array);
// обычные // "1" Обчыная страница
if ($GLOBALS['TSFE']->getHash() != null) {
// кэшировать можно
}
// useCashHash = 1 // "2" виртуальная страница
if ($GLOBALS['TSFE']->cHash != null){
// кэшировать можно
}
// Не для кэширования // "3" запрещенная к кэшированию - виртуальная страница
if (($GLOBALS['TSFE']->cHash != null && $GLOBALS['TSFE']->cHash != $cHash_calc)
OR ($GLOBALS['TSFE']->cHash == null && $cHash_calc != null)){
// кэшировать запрещено!
}
А с тэгами - наверное - если в memcache - ничего не получится - то останусь на БД:)
Т.к. по тэгам хочется иметь что - то вроде
//[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][commendId]...
//[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][newsId]...
ТЭГИ ::: https://code.google.com/p/memcached-tag/wiki/HowToUseMemcachedTag
Пока как-то так.
Использую memcache - тэги можно хранить в БД.:)
Немного по поводу сброса по тэгам...
Есть 1-страница - к примеру...
На ней работают два плагина:
Плагин А) - список новостей
Плагин Б) - список статей
Каждый из плагинов создает виртуальные страницы с useCachHash...
И добавим такой сложный элемент как постраничная навигация для каждого из плагинов.
При добавлении новости или статьи - нам же придется все равно сбрасывать весь кэш страницы с useCachHash - что бы заново пересчитать постраничную навигацию - или же делать так, что бы сбрасывался конкретный планиг - что думаю приведет в последствии к немалой путанице при поддержке проекта...:)
dmartynenko
06.12.2013, 13:49
Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина.
Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина.
Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина.
Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина.
Не совсем сообразил в плане рассчетов по умножении и получению 1 000 000 записей в кэше.
1 страница - на ней два плагина:
первый плагин генерирует 1000 виртуальных страниц через useCachHash
генерирует 15 постраничных страниц (к примеру)
typolink = index.php?id=95&tx_my_ext_1[record_detail]=1&useCachHash=1
typolink = index.php?id=95&tx_my_ext_1[pagination]=1&useCachHash=1
второй плагин генерирует 1000 виртуальных страниц через useCachHash
генерирует 25 постраничных страниц (к примеру)
typolink = index.php?id=95&tx_my_ext_2[record_detail]=1&useCachHash=1
typolink = index.php?id=95&tx_my_ext_2[pagination]=1&useCachHash=1
1000 + 15 + 1000 + 25 = 2035 виртуальных страниц, ну и + 1 страница, на которой эти плагины работают...:)
откуда мильёон?
И еще все таки интересно раз уж тут тема про кэширование идет...
Посмотрел и прикинул вообще по коли-во оращений к БД у TYPO3 - и в сравнении с другими CMS...
Вот есть такое (с других форумов):
Сильно удивился по поводу 25 запросов... поставил с нуля OpenCart 1.5.1.3.1
Главная страница
SEO выкл. - 105 запросов
opencart1531_home.png
SEO вкл. - 176 запросов
Проверил сейчас у себя сколько запросов с главной страницы:
totalProcessTime - 0.11311507225037 sec
Queries - 98.
Queries time - 0.01339316368103.
Мне кажется отличный результат. На главной странице выводится:
8 последних товаров
5 рекомендуемых товаров
Аккордеон меню с 15 категориями (без счетчика количества товара)
Стена категорий (плагин)
1
У меня на одном из сайтов на TYPO3 - получается при
генерации главной ~ 125 - запросов
в закэшированной состоянии ~ 50 запросов:)
А у чистых версий TYPO3 (например inducation c realurl без ***_INT), так и вообще получается наверное где-то 10-15 запросов через exec_SELECTquery()
dmartynenko
09.12.2013, 13:34
Если можно ходить по страницам одного плагина, и другого независимо. И при этом запоминаются обе позиции. То есть плагины учитывают piVars друг друга, то получиться 15 * 25 возможных вариантов записей в кэше со списками. Или вы открываете single одного плагина, и при этом остается виден список другого с постраничной навигацией.
Это не совсем реальный случай конечно.
Но вот более реальный.
Берем список tt_news + плагин календаря к нему + список категорий tt_news на той же странице. Календарь может генерировать очень большое число страниц сам по себе - отдельная страница на каждый день + на каждый месяц. Категории служат фильтрами внутри дня, месяца - поэтому в piVars категории добавляется дата. Получаем на каждый день у нас число уникальных url (страниц) равно числу категорий. Плюс возможная постраничная навигация внутри всего этого.
Тут тоже не совсем то, но дело плохо. При таком варианте забьется и кэш страниц, и внутренний (если делать через него), и кэш RealURL. Оптимальное решение в таком случае - вообще не кэшировать. И не давать поисковикам индексировать все этого. Так как уникального контента в этих тысячах страниц 0%.
Если можно ходить по страницам одного плагина, и другого независимо. И при этом запоминаются обе позиции. То есть плагины учитывают piVars друг друга, то получиться 15 * 25 возможных вариантов записей в кэше со списками. Или вы открываете single одного плагина, и при этом остается виден список другого с постраничной навигацией.
Это не совсем реальный случай конечно.
Но вот более реальный.
Берем список tt_news + плагин календаря к нему + список категорий tt_news на той же странице. Календарь может генерировать очень большое число страниц сам по себе - отдельная страница на каждый день + на каждый месяц. Категории служат фильтрами внутри дня, месяца - поэтому в piVars категории добавляется дата. Получаем на каждый день у нас число уникальных url (страниц) равно числу категорий. Плюс возможная постраничная навигация внутри всего этого.
Тут тоже не совсем то, но дело плохо. При таком варианте забьется и кэш страниц, и внутренний (если делать через него), и кэш RealURL. Оптимальное решение в таком случае - вообще не кэшировать. И не давать поисковикам индексировать все этого. Так как уникального контента в этих тысячах страниц 0%.
Т.е. получается примерно
Плагин А)
tt_news[detail] = 1-1000
tt_news[page_number] = 1-10
tt_news[page_number] = 1-10 &(+) tt_news[detail] = 1-1000
tt_news[calendar_data] = 10-10-2010 &(+) tt_news[page_number] = 1-10 &(+) tt_news[detail] = 1-1000
и все это суммируется
Плагин Б)
аналогично...
Да... так получается очень много.
Тогда ясно о чем речь.
Ну решение (может быть):
1) кэшировать в другие таблицы, скажем как это делает tt_news (в его cf_tt_news_cache) - хотя если на всем сайте (caching framework) - перевести на другой дравйвер, например Memcache - то не вижу смысла плодить кэш-таблицы cf_***...
2) кэш можно вырубать скажем на тех стран которые с большой долей вероятности не будут посещены пользователем... Например
- а) календари старых дат (кэшируем только тридцать последних 90 дней - к примеру, а то и меньше),
- б) page_number > 10
- в) news_detail > 100
--
И все кэша уже не будет так много.
А по этим страницам всеравно будут ходить больше всех наверное боты.
3) и пожалуй пока сложно реализуемое средствами typo3 и typoscript
если взять практически любой сайт - то - (по моим наблюдениям) - основную долю веса (приерно 20-30-400-500 а то и больше %) страницы в кэше составляет условно говоря "горизонтальное , вертикальное" меню... ну скажем классика сайта... Соответственно если кэшировать это меню 1 раз... То весь кэша уменьшается на порядок...
dmartynenko
09.12.2013, 17:09
Решения сложных случаев конечно можно найти. Но оно будет чаще всего не универсально :)
И технология "cHash" в случае сложных сайтов скорее минус, чем плюс.
dmartynenko
09.12.2013, 17:24
3) и пожалуй пока сложно реализуемое средствами typo3 и typoscript
если взять практически любой сайт - то - (по моим наблюдениям) - основную долю веса (приерно 40-50 а то и больше %) страницы в кэше составляет условно говоря "горизонтальное , вертикальное" меню... ну скажем классика сайта... Соответственно если кэшировать это меню 1 раз... То весь кэша уменьшается на порядок...
Вот-вот.
Грубо говоря, если меню сделать USER_INT с внутренней логикой кэширования, то мы сильно разгрузим кэш.
И этот велосипед уже изобрели http://forge.typo3.org/projects/extension-coago и благополучно забросили. Не все там работает так, как заявлено.
А потом снова переизобрели http://docs.typo3.org/typo3cms/TyposcriptReference/Functions/Cache/Index.html
Последний я еще не пробовал. Возможно, это решение многих проблем прямиком через TS.
Вот-вот.
Грубо говоря, если меню сделать USER_INT с внутренней логикой кэширования, то мы сильно разгрузим кэш.
И этот велосипед уже изобрели http://forge.typo3.org/projects/extension-coago и благополучно забросили. Не все там работает так, как заявлено.
А потом снова переизобрели http://docs.typo3.org/typo3cms/TyposcriptReference/Functions/Cache/Index.html
Последний я еще не пробовал. Возможно, это решение многих проблем прямиком через TS.
COA_GO - не использовал, т.к. она для старых версий TYPO3...
И в 4.7. - уже по моему не работает...
---------------------------------------------
И одну очень интересную особенность у TYPO3 - нашел.
Допустим у нас есть страница
http://company.ru/about/
Она весит в закешированном состоянии...
Ради интереса изменяем информацию на странице (таблица pages) - через phpMyAdmin - просто меняем название страницы
Заходим сюда:
http://company.ru/about/ - изменений не видим
Заходим сюда:
http://company.ru/about/?no_cache=1 - изменения видим!
Как знаем, no_cache - параметр можно заблокировать
Заходим сюда!!!!
http://company.ru/about/?blablablablalb=1231123 - изменения видим!!!
Что довольно странно!!!
Получается, что добавляя всякую ерунду к url-адресу, TYPO3 показывает ее с просто с выключенным кэшем... - интересно!
Т.е. по идее любой бы пораметр который бы не добавили к url
&print=1
&print=-1
&print=blablabla
&blablabla=print
- это будет аналогично добавлению no_cache=1:)
Работает на vBulletin® версия 3.8.1. Copyright ©2000-2025, Jelsoft Enterprises Ltd. Перевод: zCarot