|
Всетаки - кэширование с использованием БД - это очень не удобно!
Получается, что бы сделать рез.копию хостинга...
Надо проходится по таблицам... Да и потом - БД - ведь по идее созданы для полезного контента - а не для мусора (временного)... Это все равно что я бы в Ecxel таблицах в каждый из своих документов с отчетностью вставлял бы жопу павлина... Просто так... Кусочек мусора... Если бы все кэширование проходило и сохронялось в папке typo3temp - да и вообще весь мусор, все временное - что можно бы ло бы удалить - было бы гораздо лучше... Будем искать расширения на данную тему... Они есть - но как то сложно ставятся... Гораздо удобнее так делать копию хостинрга Да и БД - т.к. они не будут весить по 1 ГБ и более. |
Ну есть в Планировщике задачи по уборке мусора... Можно это делать и в ручную. Во вторых, я не пользуюсь встроенным поиском - может и стоит попробовать новый, но как-то руки не доходят, легче поставить сторонний гугль или яндекс.
Ну а сам механизм INNO в DB подразумевает "раздувание" файлов. Одно спасение - периодическое воссоздание базы данных. Ну а кеширование во временных файлах довольно широко используется... |
Цитата:
БД - должна быть для полезного контента - а не для мусора - по крайней мере я к такому выводу прихожу... Читая статьи про кэширование - почему typo3 - выбрала по умолчанию именно этот вариант, а не на файла - так и не понял аргументов... Цитата:
А если нужен действительно хороший поиск - то ручками. Цитата:
Зачастую народ херачит БД - прямо как есть - 50 мб. - 100 мб. А потом и больше ... И поробуй это все потом восстанови перенеси - начинаются всякие ограничение на время работы, заливки всяких дамперов и прочеее... Хотя если взять к примеру самый простой сайт моего студ.совета - studsovet-life.ru - здесь чистый вес БД - всего 2мб.... А если есть хостинг - где висят 5-7 проектов typo3 - то уже очень большая проблема делать рез.копию всего этого дела... Мне каждый раз приходится протыркивать каждую Бд... А так, я бы мог сделать общую копию БД - и она бы весила МБ - 20-30... -- В общем - в будующем буду уходить от этого бреда - когда кэш пишется в БД... Т.к. ЭТО ДЕЙСТВИТЕЛЬНО БРЕД. |
Согласен... При установке нового ядра иногда приходится и папку с темпами удалять, да и не только при этом, но и зачастую при разработке непонятки бывают. А так - права на папку для временных файлов поставил, и не нужно кеш чистить - запись запрещена :)
|
Цитата:
Туда же все пишется все ... и css и js - и спрайты - одним словом все... + картинки, которые создаются как временные "Тип контента изображение" -- все туда... В общем поищем решение - после отпишемся... ЖОПА - ЖОпа... эти кэши в БД... |
Да это я вроде как "пошутил", запрета ставить нельзя, так как при этом ошибки появляются - невозможно записать какой-то файл... Это я по аналогии с мультишопом - там как раз кеширование в файлы используется, ну и при изменении данных иногда чистить кеши приходится - ну вот запрет на запись помогает...
|
Для кеширование в базе есть серьезные основания:
1. Сайт может функционировать на одном сервере, а БД быть на другом 2. На нагруженных сервера с большим объемом памяти можно вывести всю базу в оперативку и тогда отклик будет существенно быстрее, чем при работе с файлами |
Цитата:
Цитата:
На сайте typo3 - тоже про это говорится... В общем второй вопрос - это очень сомнительный вопрос о том что лучше... Для меня пока в любом случае лучше файлы (по крайней мере для сайтов из 10-250 страниц это уж точно!) НИгде нет однозначного ответа о том, что лучше... http://alexvolkov.ru/bd-bystree-fajjlov.html http://hashcode.ru/questions/28006/p...B0%D0%B9%D0%BB ( сразу первый ответ - ( http://habrahabr.ru/qa/26867/ В общем-то проблема в том, что я делая рез.копии несколькох проетков - 1 хостинг - получаю по сущетству содержимое + мусор - и это уже достало... // Вот что еще пищут на хабре. Кстати, файловая система — это тоже в некотором роде база данных. |
Ну подоплека в том, что могут быть ограничения по доступному дисковому пространству, могуть ограничения по количеству файлов - ограничения могут быть какие угодно.
Для бэкапов без мусора достаточно использовать sypex dumper - можно отметить содержимое каких таблиц не включать в дамп и все. |
Цитата:
Цитата:
Второй вариант - размещать сами базы на RAM-диске. А это весьма стремно - при перезагрузке теряются и базы и структуры и подключение их к MySQL Так что при наличии большого объема памяти кэшировать лучше либо в файлы на RAM-диск, либо на решения вроде memcached/redis. |
Цитата:
Цитата:
|
Эээээ...
Не думал, что когда нибудь такое скажу... НО мне даже очень понравилось кэширвоание на основе БД....:):):) Как ни будь расскажу почему (единственный минус конечно когда на хостингах жмешь кнопку рез. копии, то база вся дампится)... |
Даже smarty - кэш переведу на БД (с такой возможностью)...
|
Вы лучше напишите "почему". Обещали :)
От себя приведу такой пример. На одном сайте в таблице 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 таблиц, получилось примерно одинаково. |
Цитата:
К примеру у нас есть новости на сайте: Они выводятся в новостях (список новостей с потраничной навигации) сама новость новость в карте сайта блок последних новостей на главной странице блок новости в слайдере на всех страницах... кроме того, может быть в sitemap... Мы можем по определенным тэгам сбросить все это при изменении/добавлении новости - и нет необходимости сбрасывать кэш всего сайта - но это очень актуально на больших и посещяемых проектах... Хотя все таки думаю - что даже это все дело потянет хороший хостинг... Подобную матрешку - пробовал реализовать на файлах... Но, к сожалению, очень не гибко в сравнении с Файлами. 2) С точки зрения записи файлов на кэшах - не знаю почему - но мне показалось что это работает по скорость также как и на БД, а вот с позции манипуляций кэшем на файлах - как-то дольше - в т.ч. удаление.:rolleyes: А с точки зрения минусов - есть один минус, который по прежнему к сожалению вижу... Таблицы кэширования лучше всего переводить в отдельную БД... Т.е. специально для кэшей держать отдельную БД... А то при бэкапах хостинга обычно он бэкапит все в одну кучу... А так было бы 1. Дамп Контента 2. Дамп Кэша (только структура) 3. FTP |
Так вы не внимательно читаете, что я предлагаю выше.
Да, работать с тэгами в БД удобней всего. В файловом кэше их попросту не сделать. В 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/20081029we...mcached-5.html) |
Цитата:
Здесь нужно "собирать опыт" :) Только одно - memcached - для меня не удобно... |
Может кому-нибудь пригодится...
Попробовал перевести кэширование на memcache PHP код:
Теперь таблицы 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-человек на сайт - и первый запустил процесс записи кэша, а остальные - им либо ждать пока запишется кэш, либо как? |
Тоже пока используем 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 Цитата:
Цитата:
|
Цитата:
Про тэгизацию все таки поищу... Думаю что есть алгоритмы - за столько лет существования этого memcache.:) |
Цитата:
Таблицы realurl вряд ли можно вынести в memcached. Во первых в memcached не структурированные данные, и возможно realurl по разным полям поиск делает. Во вторых, у нас на одном проекте до 2 гигов таблицы realurl занимают. Сильно жирно столько памяти на один realurl выделять :) |
Алгоритмы то есть, и описаны (я недавно постил ссылки на пару). Только все они требуют вместо одного запроса делать много на каждую операцию. А это ведет с уменьшению полезности memcached.
В дополнение к этому, и это пишут как минус в http://wiki.typo3.org/Caching_framework, тэги и данные могут быть удалены memcached произвольно и независимо друг от друга. Ведь memcached это такая штука, которая ничего никому не гарантирует "by design". |
Цитата:
Можно сделать "еще одну молнию на основе этого SSH->PHP скрипта" - при нажатии на нее будет создаваться бэк ап БД сайта и ложится в папку fileadmin/__temp__/ - но пока не знаю на сколько это нужно? Либо еще круче - нажал на кнопку и получил бэкап БД. Просто я обычно делаю дамп БД через Админер - после нажатия на синию молнию (ну восстановятся кэши потом - не 100 раз же на дню я ее нажимаю синуюю молнию) - получаю чистую БД без кэшей... -- Просто все таки стремлюсь сделать саму БД - чистой. Вот как таблица excel - мы же пишем там только нужные данные, а весь старый мусор бросаем в корзину... |
В общем по тэгам - тогда посмотрю и напишу в эту тему.:o
|
Цитата:
Можно очисть кэш конкретной страницы по ID-страницы. А вот очистить кэш расширения, сгенерированного через useCacheHash - уже не получится... Но думаю, что здесь все равно с тэгами особо большоего смысла углублятся в "извращения" нет.... Не знаю на сколько сложная логика кэширования реализована на typo3.org - но думаю там все предельно просто, добавил - сбросил. А где то наверное и вовсе Не кэшируется. И все работает! При БД в 70Gb и посещаемостью наверно достаточной. |
Так вы же не знаете что там за железо. Может там отказоустойчивый кластер из 50 серверов: 10 на БД, 10 на статику, 20 на фронтенд и 5 на бэкенд, и 5 еще на какую-нибудь хрень :)
|
Цитата:
Вот с тэгами сейчас разбираюсь и посмотрю есть ли смысл заморачиватьс по схеме... При добавлении новости: 1. сбросить карту сайта sitemap.xml 2. сбросить карту сайта - страницу 3. сбросить главную 4. сбросить баннеры (последние новости) 5. сбросить постраничную навигацию 6. сбросить комментарии к новости -- x. и т.д может и нет особо большого смысла так по тегам заморачиваться... а лучше вкладываться в железо... - для которого есть кэш, нету кэша - как то особо разницы нет - добавил новость и спбросил "Все разом" - хотя на моей практике был один такой человек с которым сталкивался и он хихикнул - "А что добавли и весь кэш сбрасывать??". Но без кэша думаю что на любом железе не актуально. |
Ну пока из наблюдений - что мне показалось в отличие от файлов - это то что запись в memcache - как-то быстрее происходит....:)
|
Как раз "при добавлении" - это самый хитрый момент в чистке кэшей.
Обычно как: вывели список новостей, закэшировали, в качестве тэгов использовали id-шники новостей. Соответственно при изменении или удалении (скрытии) новости одновременно сбрасываем кэши по "тэгу id-шнику". А новая новость еще ни с какими кэшами-тэгами не связана! Так что сбрасывать? PS: На тестовой машине, когда кэшей мало считывание из файла и из memcached, ИМХО, может быть одинаковым по времени. Так как обращение к файлам ОС + ФС кэширует в памяти, и получается по сути то же самое. А вот в реальной жизни, когда кэшей много, всю ФС в память не поместишь и разница будет. |
Цитата:
В этом нет ничего плохого... С memcache - конечно лучше стало (имею в виду, то что удалось поставить на memcache)... И это заметно даже на не большой проекте. Единственное проблема с которой столкнулся при использовании memcache - это на основе чего генерировать уникальный ключ кэша - что бы разрешить запись кэша? На основе id-страницы - не подходит На основе useCacheHash - также не подходит В обоих случаях пользователь может ввести id=xxxx - и будет создан кэш + 1... И таким образом будет насоздано куча всяких "несущесвующих" кэшей. А с тэгами ищу решение... |
Цитата:
Ищу тэги для memcache...:cool: |
В общем случае ключ в кэше должен учитывать все что у вас может повлиять на содержимое. Т.е. id страницы, текущий type, GET переменные, содержимое config и т.п. И еще место откуда вызывается.
Примерно так PHP код:
|
Цитата:
1. вот человек ввел id=5005034 (у нас движок выдаст 404 - ошибку) - сам просчитает, т.к. такой страницы нет, и для type - тоже самое а вот если мы используем показ новостей к примеру по additionalparams для typolink - пример tx_news[id]=50 получается если человек от "себя" введет не верный id-записи, то у Вас запишется кэш +1 - которого в принципе не существует. И так до тех пор, пока он (злоумышленник-вредитель) не устанет вводить разные значения - одним словом так и сайт можно "завалить".... Получается как - каждый раз проверять на существоание такого ID, и если есть, то разрешаем писать кэш? Как проверить валидность id-записи? 2. вот мое наблюдение по работе ядра системы: если у нас запрашивается не верная страница по id, type - то typo3 в кэш ничего не пишет - здесь вродебы все ясно... но вот как она проверяет additionalparams, в т.ч. useCachHash - что это валидный url? Как я не старался - все равно она лишних кэшей никаких не пишет... Даже useCachHash = FALSE Цитата:
|
С левыми id проблем не вижу.
Вы же делаете как: 1. Строите cache_key 2. Проверяете в кэше 3. Если нет, то делаете запрос в БД 4. Если нет записи - выдаете 404 5. Если есть в БД, формируете контент и пишете в кэш Логично что ответы 404 в кэш писать не нужно. Цитата:
|
Цитата:
Возможно нашел решение - более простое - по поводу разрешить/запретить кэширование - но оно связанно с useCashHash - и не знаю насколько оно будет уместно ... И сейчас не совсем пойму - почему useCashHash так плох? Цитата:
PHP код:
|
Это то, что так долго искал - наверное не 1-и месяц:
самое странное что в тему useCashHash valid - на оффициальном форуме typo3.org - мне ничего не ответили, вернее ответили, но как-то расплывчато было сказано - что это не возможно - и это ответ от Core...!!!... Странно что там, даже PHP-код вставить нет возможности.... Теперь из t3lib_div::cHashParams и t3lib_div::calculateCHash стало понятно, как можно проверить ... useCashHash - оказывается - это просто md5 - всех _GET-параметров.... PHP код:
Т.к. по тэгам хочется иметь что - то вроде Код HTML:
Пока как-то так. |
Использую memcache - тэги можно хранить в БД.:)
|
Немного по поводу сброса по тэгам...
Есть 1-страница - к примеру... На ней работают два плагина: Плагин А) - список новостей Плагин Б) - список статей Каждый из плагинов создает виртуальные страницы с useCachHash... И добавим такой сложный элемент как постраничная навигация для каждого из плагинов. При добавлении новости или статьи - нам же придется все равно сбрасывать весь кэш страницы с useCachHash - что бы заново пересчитать постраничную навигацию - или же делать так, что бы сбрасывался конкретный планиг - что думаю приведет в последствии к немалой путанице при поддержке проекта...:) |
Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина.
Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина. |
Цитата:
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 страница, на которой эти плагины работают...:) откуда мильёон? |
| Часовой пояс GMT +4, время: 03:31. |
Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot