Не знаю как кто, но лично мне довольно часто нужно использовать какой либо кеш при написании хаков, чтобы лишний раз не дергать базу. Стандартная система кеширования vb (класс vbDatastore) не совсем подходит, т.к. она оптимизирована под один большой запрос всех данных при инициализации vb (еще до Init хука) и даже если используется любой внешний (xcache, ea, apc, memcached) все равно пишет дубликат в базу (datastore), как следствие этот класс не совсем подходит для частого изменения кеша, например для хаков типа чата (для информации - нет ни одного нормального чата для булки выдерживающего нормальные нагрузки).
Написать что-то жестко заточенное под конкретный кеш для меня не составляет проблем, но это совсем не подходит для публичных хаков, т.к. очень жесткая заточка под конкретную конфигурацию сервера, да и не красиво это.
Может есть у кого или универсальный класс не конфликтующий со стандартным классом булки для однотипной работы с xcache, ea, apc, memcached. И конечно желательно проверенный в работе, т.к. классов существует много, и проверить совместимость и не конфликтность со стандартным классом я могу только для xcache (под хорошей нагрузкой) и ea (без нагрузки).

P.S. Вообще-то уже и сам написал такой класс на базе класса булки и по идее он не должен конфликтовать со стандартным (для xcache точно работает без проблем под нагрузкой), но протестировать для всех кешей не было возможности (особенно критична совместимость со стандартным классом vb memcached-а, т.к. там коннекты к серверу, флаг подсоединенности и т.д. и т.п.).

Добавил файл с функциями расширяющим функционал обращения к варкешу (датастору). Расширение в плане прямого добавления/ прямого извлечения / прямого удаления записей из кеша + работа с TTL.

Работает с eAccelerator, XCache, APC
Не работает с Filecache и Memcached. Первый (Filecache) даже не рассматривал ввиду его скорости, второй не было где нормально протестировать (да и скорость у мемкеша тоже не очень)

Функции:
isenabled_datastore() - проверка что включен поддерживаемый датастор
get_datastore($title, $unserialize_detect = 2) - прямое извлечение записи из датастора (unserialize_detect аналогичен стандартному функционалу vb) возвращает null если запись извлечь не удалось
set_datastore($title, &$data, $ttl=null) - запись данных в датастор
delete_datastore($title) - удалить запись из датастора.

Все производимые операции с датастором никак не трогают датастор в базе, т.е. это не столько использование датастора, а сколько небольшая навеска для прямого использования установленного варкеша.

что ты собрался кешировать на форуме, в котором права доступа для каждого юзера уникальны и кеш чего угодно сразу устаревает после появления нового сообщения ?
Глобальные данные прекрасно помещаются в datastore, а чат кешированием не исправишь.

Originally Posted by netwind

что ты собрался кешировать на форуме, в котором права доступа для каждого юзера уникальны и кеш чего угодно сразу устаревает после появления нового сообщения ?

Но форум все-таки один и у всех пользователь может быть одна и та же инфа котрую нужно кешировать (не зря булка кеширует настройки, список форумов, ббкоды и много другого в варкешах, если подключен нужный класс)
К тому же это раздел для кодеров, и для обсуждения проблем кодеров (насколько я понял) и мало ли что кодер захочет закешировать. К тому же я говорил не о кеше скомпилированных сообщений булки, я о datastore-кеше, который в зависимости от конфига может использовать различные php кеши.

Originally Posted by netwind

а чат кешированием не исправишь

Как раз какой либо варкеш для чата то что нужно. Например при 200 пользователях онлайн может быть более 100 обращений в сек к списку последних сообщений в чате (который конечно подгружается ajax-ом). И выдернуть из кеша (из памяти) намного быстрее даже чем прочитать файл. Можно конечно каждый раз перегенерировать чистый html при написании сообщения (как сделано в некоторых чатах), но лучше все же использовать любой варкеш. Как следствие в скрипте, который должен выполняться очень часто можно вообще отказаться от запросов в БД. Но это уже уход от темы вопроса.
Я хотел узнать есть ли о кого проверенные наработки для работы с кешировщиками PHP, а если более точно для работы с варкешами PHP (обычно их используют как альтернативное и очень быстрое хранилище для часто изменяемых данных).

Использовать стандартный датастор очень удобно для своих скриптов с отдельными файлами, но если используются только хуки, то стандартные классы vb не совсем подходят (Обычно это добавит минимум 1 допзапрос к БД), и совсем не подходит если нужно будет частое обновление кеша.

Originally Posted by Yoskaldyr

Как раз какой либо варкеш для чата то что нужно. Например при 200 пользователях онлайн может быть более 100 обращений в сек к списку последних сообщений в чате (который конечно подгружается ajax-ом)

В том и беда, что накладные расходы на "раскрутку" php и apache будут несоизмеримо больше, чем одно обращение к mysql. Нормальный не грузящий чат на vb.org стоит - там irc-клиент на java.
Если это такая проблема - посмотри что там Котеров наваял http://habrahabr.ru/blogs/hi/69457/
Как вариант - формировать страницу сообщений чата в html и отдавать этот файл из nginx без привлечения php (приватики отдыхают)

Что касается кеширования вообще, кешируй прямо в таблицах mysql максимально обработанные блоки html. Это 100% в каждой инсталляции vb будет работать. Если таблицы маленькие и проиндексированные, то там не с чего тормозить.

Originally Posted by Yoskaldyr

и совсем не подходит если нужно будет частое обновление кеша

самому то не смешно? зачем тогда нужен кеш, если он часто обновляется, то есть фактически не используется ?

Originally Posted by netwind

Как вариант - формировать страницу сообщений чата в html и отдавать этот файл из nginx без привлечения php (приватики отдыхают)

Именно об этом решении я и писал выше (Вы видать не заметили). Чат я привел в качестве примера. Это только одно из применений для php-кешей.

Originally Posted by netwind

Если это такая проблема - посмотри что там Котеров наваял http://habrahabr.ru/blogs/hi/69457/

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

Originally Posted by netwind

Что касается кеширования вообще, кешируй прямо в таблицах mysql максимально обработанные блоки html. Это 100% в каждой инсталляции vb будет работать. Если таблицы маленькие и проиндексированные, то там не с чего тормозить.

Варкеши в PHP - это те же БД, но с доступом "key" - "value" и со скоростью работы намного быстрее чем Mysql. Например 10К рандомных запросов на чтение из кеша xcache происходит 0.025 сек, а чтение 10К из простой таблицы по индексу происходит за 2сек - разница в 100 раз как мне кажется более чем ощутимая.
Вы должны быть в курсе что mysql и myisam таблицы очень быстрые, но только когда там нет постоянных одновременных апдейтов и селектов. И если одну даже небольшую таблицу насилуют даже 20 соединений на одновременный селект/апдейт будет сильное падение в производительности.

Originally Posted by netwind

самому то не смешно? зачем тогда нужен кеш, если он часто обновляется, то есть фактически не используется ?

То что php varcache называют кешами, это не повод их использовать именно в классическом понимании кеша.

Все-таки мне кажется что Вы не поняли о чем именно я спрашиваю.

И просьба, если у Вас нет ответа по существу вопроса, не надо превращать топик в свалку. А то не хочется что-бы данный раздел превратился во флудильню и как следствие был удален.

P.S. Похоже придется брать классы из vbOptimize, там они точно проверены на совместимость с классами булки и проверены на работу под нагрузкой для всех вариантов кешированя (xcache, apc, memcached, ea), да и есть своя реализация filecache

Я хочу объяснить, что может ты и решишь конкретную узкую проблему, но для проектов в целом не выиграешь ничего существенного. Применительно к vb, уже после вызова global.php расходуется столько времени и памяти , что все попытки ускорять что-то на миллисекунды - мертвому припарки. Операция должна быть реально тормозной и тут уже не важно где хранить, в mysql или в кеше акселераторов.
Если так важно обновлять кеши постоянно - сделай несколько myisam-табличек.

Originally Posted by netwind

. Применительно к vb, уже после вызова global.php расходуется столько времени и памяти , что все попытки ускорять что-то на миллисекунды - мертвому припарки. Операция должна быть реально тормозной и тут уже не важно где хранить, в mysql или в кеше акселераторов.

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

P.S. И все-таки я не спрашивал о том нужно или не нужно использовать кеш, я спрашивал о классах или библиотеках для использования кеша.

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

netwind, Следуя Вашей логике даже самый простой счетчик посещений лучше всего делать используя mysql и продолжая следовать Вашей логике необходимо сделать отдельную небольшую таблицу для счетчика.
Да при небольших нагрузках мускуль справится без проблем, но вот при нагрузках немного больших средних - все будет очень "быстро" и "прооптимизированно"....

Originally Posted by netwind

другая, не менее частая проблема - преждевременная оптимизация

Хак изначально должен быть правильно написан, чтобы его потом не надо было оптимизировать.
Правильно написанный хак не должен сильно замедлять работу булки и по возможности не должен добавлять дополнительных запросов в БД. Все-таки таких хаков может быть установлено не один десяток. А на практике из всех текущих хаков для булки меньше 1% написаны более менее вменяемо с правильным использованием vb-api.

А так вообще разговор ни о чем... :(
Оффтоп

netwind, А сколько хаков для булки написали лично Вы? Не перевод, не небольшие исправления существующих, а именно написание с нуля

Originally Posted by Yoskaldyr

А на практике из всех текущих хаков для булки меньше 1% написаны более менее вменяемо с правильным использованием vb-api.

Тем не менее, если почитать обсуждения, 99% хаков устраивают их пользователей по скорости работы. Основные претензии только к функционалу. Я понимаю - у тебя специфические задачи и они сформировали специфическое мнение. HTTP-трекер на php вообще изначально неправильный и неудобный протокол для файлообмена. Нагрузки, сходные с автоматическими запросами постоянно дрюкающего торрент-клиента очень непросто достичь обычному форуму.

Хаков я написал не так много и они были обычные народные не связанные с варезом или кешированием всего и вся на ограниченных ресурсах. Datastore использовал один раз в баннерной системе - там где действительно нужно.