Кэширование MySQL

[Veseloff]

Итак, тут попался сайт один на «улучшение», который изрядно заполнился контентом и стал жутко тормозить. Сделан сайт «так себе» — руки программиста росли не совсем из того места, и прикручивать туда кэширование блоков и шаблонов будет дольше, чем написать его с нуля. Посмотрел что именно тормозит — тормозят запросы в мускуль. Есть там лютые джоины, которые по 0.5-2 секунды работают. Доступа к настройкам MySQL сервера нету из-за хостера, площадку и тариф менять они не хотят. Оптимизировать БД тоже особо без толку — все индексы на месте, но сама архитектура хромает. Переделывать архитектуру ­≈ написать всё с нуля. Из-за некоторых особенностей memcached неприменим. И вот я задумался о кэшировании результатов запросов. Алгоритм мне в голову пришёл такой:

1. Делаем запрос в БД, получаем результат, формируем массив из записей.

2. Берём md5 от текста запроса

3. Делаем serialize результата, сохраняем его в файл с названием %md5 из третего пункта%. Конских размеров файла не будет — результаты запросов все не особо длинные, просто сами запросы плохие.

4. При следующей выборке проверяем существование файла с именем %хэшем текста запроса% и, если он есть, то делаем unserialize и отдаём результат.

Нормальный вариант или можно как-то лучше, проще, быстрее?

[CoDy]

Я на Joomla как то ставил плагин, который работает по такому принципу. Но только там данные не сеарилизовались, а использовался PHP Accelerator и данные кэшировались в опкоде. Прирост в быстродействии был ощутимый.

[s0rr0w]

Итак, тут попался сайт один на «улучшение», который изрядно заполнился контентом и стал жутко тормозить. Сделан сайт «так себе» — руки программиста расли не совсем из того места, и прикручитивать туда кэширование блоков и шаблонов будет дольше, чем написать его с нуля. Посмотрел что именно тормозит — тормозят запросы в мускуль. Есть там лютые джоины, которые по 0.5-2 секунды работают. Доступа к настройкам MySQL серера нету из-за хостера, площадку и тариф менять они не хотят. Оптимизировать БД тоже особо без толку — все индексы на месте, но сама архитектура хромает. Переделывать архитектуру ­≈ написать всё с нуля. Из-за некоторых особенностей memcached неприменим. И вот я задумался о кэшировании результатов запросов. Алгоритм мне в голову пришёл такой:

1. Делаем запрос в БД, получаем разультат, формируем массив из записей.

2. Берём md5 от текста запроса

3. Делаем serialize результата, сохраняем его в файл с названием %md5 из третего пункта%. Конских размеров файла не будет — результаты запросов все не особо длинные, просто сами запросы плохие.

4. При следующей выборке проверяем существование файла с именем %хэшем текста запроса% и, если он есть, то делаем unserialize и отдаём результат.

Нормальный вариант или можно как-то лучше, проще, быстрее?

Абсолютно нормальный способ кеширования.

[vasa_c]

Если запросы дословно одинаковые, то mysql закэширует их сам, более того, он гораздо лучше разберётся с инвалидацией этого кэша.

[Veseloff]

Если запросы дословно одинаковые, то mysql закэширует их сам, более того, он гораздо лучше разберётся с инвалидацией этого кэша.

Да, я об этом прекрасно знаю. И вообще, по-хорошему, настройки сервера можно (и нужно) «подстроить» под железо, под конкретные запросы, вынести кой-чего в tmpfs... Но не всегда это всё настраивается так, как это хочется клиенту. Особенно на площадках виртуального хостинга, где всё общее. Всем спасибо за ответы. Пожалуй, так и поступлю, если еще что-то не придумаю за выходные.