Дневник программиста

Linux наше всё :/

 

Можешь поробовать для начала сделать как в 2.2 и выше: изменить в ipsclass::init_load_cache и ipsclass::update_cache запись в БД на запись в кеш. Заодно замерь в начале время выполнения ipsclass::init_load_cache, мне интересно насколько замена местонахождения кеша ускорит загрузку

Я только не уверен, что везде используется update_cache, может кто-то решит в БД писать, не зная про новый кеш.

Если нет доступа к исходникам какого-нибудь high-load проекта, посмотри хотя бы код тройки. Там одна универсальная библиотека-обвёртка и к ней драйверы для работы с разными типами кешей.

 

Конкретно по cache_store конкретно для двойки -> там есть обвёрточная функция $ipsclass->init_load_cache(array...);

 

Вместо запроса по IN пишем примерно такой код:

 

foreach(нужные кеши)
{
if( !$data = cache::get('имя отдельного кеша') )
{
	$data = $this->DB->загружаем данные из базы
	cache::set('имя кеша', $data);
}
}

 

А в самой базе вешаем триггер на событие update & insert & delete -> drop_cache('имя кеша');

Обычно есть специальные расширения для СУБД, которые позволяют им управлять кешами.

 

Значит, что получается..

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

 

Что и как желательно прятать в этот самый кеш?

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

 

2Sannis, за очень редким исключением, крайне не рекомендуется напрямую писать в кеш данные, оригинал которых хранится в БД. Это рано или поздно приведёт к тому, что данные в кеше будут повреждены, либо неактуальны. Лучше его drop'ать по каждому поводу, чем мучительно ловить баги и писать километры функций.

мне интересно насколько замена местонахождения кеша ускорит загрузку

 

В 10-100 раз быстрее *_query, плюс разгрузка СУБД в пользу других запросов, что даже более важно.

2Sannis, за очень редким исключением, крайне не рекомендуется напрямую писать в кеш данные, оригинал которых хранится в БД. Это рано или поздно приведёт к тому, что данные в кеше будут повреждены, либо неактуальны. Лучше его drop'ать по каждому поводу, чем мучительно ловить баги и писать километры функций.

Наверное я к вечеру туго соображаю. В предложенном вами варианте всё равно будет две копии -- в БД и в кеше, что-то противоречие. Под "$data = $this->DB->загружаем данные из базы" имеется в виду запрос с cache_content или непосредственно генерация кеша по исходным таблицам?

 

Собственно я и не предлагал перелопачивать весь код, достаточно две функции заменить. А от кеша в БД избавиться, полностью заменив его кешем в памяти.

В предложенном вами варианте всё равно будет две копии

 

Там логика следующая: желательно не допускать ситуаций, при которых будет код:

$DB->update(...);
$cache->update(...);

Любая из двух операций может быть выполнена с ошибкой, что вызовет расхождение.

 

Должно быть:

$DB->update(...);
$cache->drop(...);

 

Собственно я и не предлагал перелопачивать весь код, достаточно две функции заменить. А от кеша в БД избавиться, полностью заменив его кешем в памяти.

Увы, нельзя. Кеш - штука ненадёжная, может умереть по десятку причин.

драйвера я уже посмотрел на момент написания поста, они достаточно просты

упрячу туда всю таблицу cache_store, обновлять xcache можно только двумя подряд действиями - сначала полное стирание какого-то элемента, потом его полная запись

еще у меня в галерее есть кеш изображений, который я уже сам делал -> xcache, обновление по таску раз в x часов

ну и все такие подобные большие массивы

Установил xcache1.3.0 и php5.2.11 заодно

Умерла поддержка gd png...

Пришлось использовать bundled версию gd

Но оно не хуже имхо

 

'./configure' '--with-mysql=/var/db/mysql/' '--with-apxs=/usr/local/sbin/apxs' '--with-png-dir=/usr/local/lib/' '--with-jpeg-dir=/usr/local/lib/' '--with-freetype-dir=/usr/local/include/' '--with-gd' '--enable-gd-native-ttf' '--with-zlib' '--enable-mbstring'

Итак последние данные.

 

На главной время генерации со всеми панелями не превышает 0.35 сек (было замечено 0.8 перед установкой)

В темах не превышает 0.1

В галерее убрал в кеш все,что мог - с 0.8 до 0.4

 

Странное наблюдение - не все элементы почему то убираются в xcache

Наверно там есть настройка ограничения размера одной переменной?

С вероятностью 99% - есть.

Например, мемкеш вроде до 1 мегабайта принимает.

Увеличу размеры всего этого барахла, в том числе мемори лимит php

Ибо скорость возросла, но и возрос показатель нагрузки. Что он значит, не очень понимаю особенности freebsd, но он постоянно в районе 0.2 и бывает больше

Плюс убрал в кеш таблицу skin_sets, ибо к ней запрос длился дольше всего (в кеше она была, но только ид и прочая мелкая цифровая ерунда, убрал же всю целиком, для 2 стилей размер допустим, для большего количества - может быть злом и надо будет убирать каждый стиль отдельно)

Увеличу размеры всего этого барахла, в том числе мемори лимит php

Ибо скорость возросла, но и возрос показатель нагрузки. Что он значит, не очень понимаю особенности freebsd, но он постоянно в районе 0.2 и бывает больше

Плюс убрал в кеш таблицу skin_sets, ибо к ней запрос длился дольше всего (в кеше она была, но только ид и прочая мелкая цифровая ерунда, убрал же всю целиком, для 2 стилей размер допустим, для большего количества - может быть злом и надо будет убирать каждый стиль отдельно)

Ты имеешь в виду убрал и закешированные шаблоны?

нет, там только общий шаблон форума

Я уж за сомневался. Да, несомненно стоит.

Сильно увеличил все параметры, в кеш влезло вообще все

что за кеш такой chatting? рудимент стандартного чата? фтопку?

 

Теперь на mysql по данным встроенного дебага уходит 0.01 секунда

Значит остальное - на php