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

Сегодня международный день борьбы с кэшированием.
Итак, стандартный CI предлагает нам два вида кэширования.
1. Кэширование на уровне страниц целиком
2. Кэширование на уровне запросов
Оба этих класса подробно описаны в документации, хорошо управляются из кода, и мне лень описывать как использовать.
Поэтому я лучше остановлюсь на проблемах с которыми я столкнулся в процессе их изучения.

Сразу отмечу, что кэширование это не панацея. Его роль мягко говоря "преувеличена". Кэширование снижает нагрузку на БД. Если запрос к БД у вас прямой (без подзапросов и кучи джоинов) - чтение из бд, возращение результата запроса и отображение результата - тадададам! - занимает столько же сколько чтение из файла. Но если запрос с выподвыпертом - мускул не мсскуэль, не ждите от него чудесных планов и аццкого быстродействия. Он серьезно проседает и как результат - кэширование в данном случае серьезно увеличит скорость загрузки (в моем случае - некоторые страницы открываются быстрее на порядок).

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

Итак. Закэшированно vs Незакэшированно
Память - потребляется примерно одинаково (~2Mb в моем случае)
Скорость загрузки страницы - на простых запросах - одинаково (~0.5 sec в моем случае) и вплоть до разницы на порядок (0.5 sec VS 5 sec на сложных запросах)
Нагрузка - снижается. Эффект проявляется очень просто. Ваш сайт не ложится в даун, когда на него заходят 1000 уников.
Мифы:
1. Кэширование в CI тормозит(потому что через файлы), реализовано через задницу(потому что не чистит за собой) и вообще жутко неудобное (потому что кэширует целиком)

Тормозит - Если мы смотрим постраничный кэш, то он реализован очень грамотно. Во первых тормозить там нечему в принципе. Проверка на наличие кэша делается на самой ранней стадии загрузки CI. На этом этапе ещё даже сам суперобъект CI не загружен. Т.е. буквально пару инклюдов, есть кэш - да/нет - тупо выводим контент.

Не чистит за собой. Опять враки:

<?php
// Has the file expired? If so we'll delete it.
  if (time() >= trim(str_replace('TS--->', '', $match['1'])))
  {   
   @unlink&amp;#40;$filepath&amp;#41;;
?>



Кэширует целиком - да в этом есть определенное неудобство. Но никто не запрещает комбинировать оба доступных способа. Если контент статический (ну например TOP лист пользователей или ещё чего-то - нет нужды обновлять его каждую минуту) - тупо пихаем статичный кэш всеё страницы с большим интервалом и забываем о проблеме. Надо сказать что данный способ подходит большинству сайтов. Любой сиранный бложик попадает под определение "статического сайта". Кто генерит на нем контент? Автор - дай бог раз в сутки добавляет сообщение. Нет проблем - перед добавлением записи чистим файлы в директории blogs и забываем о проблеме (при включенном кэше). И комментатры - чистим при добавлении коммента. Всё. Зверски тупо и удобно. И не надо выплясывать с бубнами и кэшировать отдельно куски типа облака тегов HMVC и т.п. ВСЮ страницу -> в кэш.

Если контент динамический - типа форума или соц. сети - тогда да, тогда жопа. Например на wharrgarble бложик для каждого пользователя свой - в зависимости от текущего пользователя показываются сообщения, для каждого пользователя/сообщения есть метка сколько комментариев в этой ветке видел конкретный пользователь и т.п. У каждого своя страница. И я побрел в лес по неверной дороге. В сторону дополнительных плагинов:
-CashedObjects
-KhCache
Оба позволяют реализовать частичное кэширование. Таким образом, например страница с 10 постами на главной имеет 10 статичных объектов (тексты записей не меняются) и кучу динамики для каждого пользователя - типа количества новых комментариев. Но в данном случае нагрузка на БД перекладывается на файловую систему, так как файл у нас уже не один - а столько - сколько записей в БД (или больше - зависит от конкретного маразма) - и в данном случае мы получаем тормоза, но уже на файловой системе. Во всяком случае мне так кажется, что данный вариант тормозить будет больше.
Тогда, остается одно - memcached (ну и другие апи для работы с оперативкой, насколько я понял мемкэшед не самый быстрый апи)
Но! Начались то проблемы с того, что у меня не выделенный сервер, а тормозной firstvds с сиранными 96 мегабайтами на борту - которые исчерпываются - и лепраэффект(сайт ложится).

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

Итого:
Я остановился на следующем варианте.
1. Вся более менее статичная информация в стандартный страничный кэш CI
2. Все тяжелые запросы - в стандартный кэш CI для работы с БД
3. Работу с динамикой - оставил на совести БД, упростив по максимому запросы и перенеся "тяжесть расчетов" на массивы пхп
Пока - полет нормальный. А как вырасту до 1000 уников - уж наверно прикуплю сервачок, и вперед и с песней с memcached!

А мораль сей басни такова - даже самый унылый говносайт написанный на говно ЦМС можно вытянуть за счет грамотно организованного кэширования. И в конечном итоге победят говно цмс-ки написанные говнопрограммистами... Даже картинку по запросу "говнопрограммист" лень искать.. ибо грустно.