Вы не зашли.
Страницы 1
DB Cache - плагин позволяет реализовать поддержку кэширования запросов на выборку данных из базы MySQL, которая используется в CMS. Это позволяет существенно снизить нагрузку на базу данных и не обращаться к ней каждый раз за данными, а лишь проверять их через определенные интервалы.
Установка (своеобразный хак)
Пока это наполовину хак, надеюсь, что пока.
1. Открыть файл CMS, находящийся по адресу /engine/core.php
2. Добавить после $mysql = new mysql; (Примерно строка 287) код: exec_acts('mysql');
3. Зайти на страничку плагина и настроить его.
4. Включить плагин.
Известные проблемы.
1. Кэшируются все запросы на выборку из базы данных.
2. Запросы, возвращающие пустые значения, не кэшируются.
3. Сброс кэша происходит только по таймауту или вручную, даже после обновления таблицы
История изменений
0.2 Добавлена возможность сброса кэша вручную
0.1 Первый публичный релиз плагина
Все последние изменения тут же появляются в репозитории проекта на GitHub или на моем сайте
З.Ы. Хочу услышать мнения пользователей о целесообразности существования плагина как такового
Держу свои сайты здесь
Самые дешевые домены
Не в сети
Сама по себе идея интересная, но есть несколько нюансов:
1. Кеширование select'ов без учёта update'ов в таблицу - очень неудобный подход. Могут быть массовые накладки, к примеру, при редактировании новостей, создании комментариев и т.д.
Т.е. такой подход абсолютно оправдан для "статических" сайтов (на которых ничего не обновляется и запрещены комменты), но не для динамических.
2. Достаточно сильное кеширование есть в самом mysql (query cache), поэтому с точки зрения кол-ва SQL запросов мы получим заметную экономию, а вот с точки зрения производительности - не факт.
3. Класс mysql нужно переделывать на mysqli, есть планы на ближайшее будущее на подобный переход.
Плагин быстро потеряет актуальность.
Не в сети
vitaly, 1. Хотел было сначала сделать сброс после обновления, но порой в этом то и суть. Допустим очень часто посещаемый сайт, считает что-нибудь, например, кол-во скачиваний файла. Я считаю, что пусть там счётчик накручивается, а каждый раз выводить новое значение необязательно. Хватит и раз в 5-10 минут обновлять. С другой да, накладки будут. Пока не придумал как научить плагин различать откуда идут запросы. Если появится разделение прав, то тут становится всё просто, если у пользователя есть права на добавление/редактирование новостей, то для него запрос не кэшируем.
2. В курсе про него. Поэтому и выложил плагин в надежде, что кто-то попробует его и скажет есть ли толк в его использовании.
3. Плагин обёртка над классом mysql, запросы он не трогает. Или планируется в связи с переходом переписать все запросы вместе с классом?
Сложновато без документации на ощупь делать плагины. Может есть уже какой-то способ в плагине узнать права пользователя?
Держу свои сайты здесь
Самые дешевые домены
Не в сети
Mark,
1. Значит надо отдельно хранить имена таблиц по которым будет сбрасываться кеш при обновлении таблицы.
Или даже определять откуда пришел вызов и решать - нужно ли обновлять кеш. К примеру, обновление таблицы ng_news из админки - явный повод для сброса кеша.
А тоже самое обновление с сайта - очень похоже на обновление счетчика и тут спокойненько всё можно кешировать
2. Да, с такой точки зрения мысль интересная. Но у меня есть подозрение, что тут ещё будет играть скорость работы mysql и memcached. Если memcached работает на другом сервере с пингами в 10ms, а mysql локально - то явно mysql будет быстрее. Ну и наоборот.
3. Планируется переписать сам класс, т.к. самая полезная фишка mysqli - передача параметров в SQL запрос.
Будет писаться новый класс, который сохранит старые функции (для совместимости) и добавит новые (с использованием шаблонов).
И паралельно будут переписываться SQL запросы на более правильный режим работы.
Сложновато без документации на ощупь делать плагины. Может есть уже какой-то способ в плагине узнать права пользователя?
Документацией по мере возможности занимаюсь, но она действительно сильно отстаёт.
Да, возможность есть.
// Check if user $user have access to identity $identity with mode $mode
// $identity - array with element characteristics
// * plugin - id of plugin
// * item - id of item in plugin
// * ds - id of Date Source (if applicable)
// * ds_id - id of item from DS (if applicable)
// $user - user record or null if access is checked for current user
// $mode - access mode:
// 'view'
// 'details'
// 'modify'/
// .. here can be any other modes, but view/details/modify are most commonly used
// $way - way for content access
// 'rpc' - via rpc
// '' - default access via site
function checkPermission($identity, $user = null, $mode = '', $way = '') {}
Пример использования в админке:
if (!checkPermission(array('plugin' => '#admin', 'item' => 'system'), null, 'admpanel.view')) {
ngSYSLOG(array('plugin' => '#admin', 'item' => 'system'), array('action' => 'admpanel.view'), null, array(0, 'SECURITY.PERM'));
@header("Location: ".home);
exit;
}
Пример использования в плагине:
$permPlugin = checkPermission(array('plugin' => 'nsm', 'item' => ''), null, array(
'view',
'view.draft',
'view.unpublished',
'view.published',
'modify.draft',
'modify.unpublished',
'modify.published',
'delete.draft',
'delete.unpublished',
'delete.draft',
'list',
'add',
));
...
if (!is_array($userROW) || !$permPlugin['view']) {
msg(array("type" => "error", "text" => $lang['perm.denied']));
return;
}
Т.е. можно запрашивать по одному плагину (админка это тоже "плагин", только с идентификатором "#admin") на выбор - права на одно действие и на группу действий.
Не в сети
ктото может чтото сказать на счет этого плагина http://ngcms.ru/components/dbcache/
он работает, нет? он реально снижает нагрузку?
Изменено legenda (2014-01-04 01:55:25)
Не в сети
ктото может чтото сказать на счет этого плагина http://ngcms.ru/components/dbcache/
он работает, нет? он реально снижает нагрузку?
С ним SQL запросов: 2 |, если отключить SQL запросов: 10. Запросов меньше, но, страница генерируеться где то на 0,06-0,07 дольше, и памяти на 120-140 килобайт больше. Проверял на Open Server
Не в сети
Страницы 1