PHP\MySQL Акселераторы

Не кешерует оно запросы содержащие "now()" или многие другие функции.

Ну, в принципе, про now() мог и соврать :-)

э? это по каким-таким тестам APC показывает худшие результаты?

AFAIK команда php тестила все кеши и, в итоге, APC войдет в PHP6 искаропки.

Про результаты запросов: есть memcached который великолепно решает эту проблему. Зачем изобретать велосипед?

В MySQL есть собственное кеширование частых запросов - возможно имеет смысл увеличить размер кэша, если сложно менять скрипты для кеширования.

Я подключал для своих сайтов apc. Кстати он не работает одновременно с zend.

Outsourcenow, так вы не ответили почему он тормозит именно в вашем приложении. hitrate хотя бы какой у вас?

хитрейт - порядка 60%. Но на той железке - около 90% апдейтов. Копеечного размера таблицы, нормированые - но с часто обновляемыми данными.

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

Outsourcenow, ну вот. 90% апдейтов в вебе это нетипично. Специфика вашего проекта совсем не дает вам право утверждать, что у mysql хреновый query_cache.

А так, попробуйте уменьшать (как ни странно) размер кеша. Сделайте профилирование. Скорее всего, накладные расходы возникают не при поиске в кеше, а при удалении затронутых обновлением запросов из кеша. Это не значит, что бороться этим явлением невозможно.

Ну, я только за себя говорить могу - поэтому такой пример и привел. Но люди, которые всерьез нанимаются тюнингом высоконагруженного mysql настоятельно отговаривали от использования кэша :-)

Не, это мертвому припарки. Там программисты уже озадачены переписыванием всего этого на мемкэше с периодическим дампом в mysql.

Outsourcenow, при этом предводитель "людей которые занимаются тюнингом" пишет статейки, как его использовать : http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/

Нестыковочка.

Дейстивтельно :-) Потому как именно Петя в 2008 году говорил строго обратное :-)