Кэширование

сам дизайн нет, но например код партнерок довольно часто меняю (тестю) и каждый раз надо чистить весь кэш ...

Первый раз встречаю задачу в которой разработчик связывает время кэширование со скоростью изменения дизайна. М.б. вы не с того боку заходите?

Ну так и кэшируйте всю страницу целиком без кода партнерки. А парнерку - отдельным кодом.

если к странице обращений больше не случится, то мусор в кеше будет храниться вечно 🚬

Бред,

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

ну так как свои сайты я полностью обслуживаю сам, то хочется учесть все возможные плюсы и минусы :)

Кэшируйте только готовый контент. А его уже впихивайте в шаблон.

вот это точно не оптимальное решение и на хорошей посещаемости эта машина уйдет сначала в LA, потом в нирвану, потом ТС напишет "Пацаны, кеш это зло" :)

кеш нужно проверять не чаще, чем это требует заача!

более того, есть мелкий момент такой ... некоторые личности перед открытием файла кеша типа open(filename) делают еще и предварительно ifexist, что не просто зло на хорошей посещаемости, а просто вредительство ...

там кто-то выше правильно отписал на предмет "мусуль кешит" - есть у меня пара проектов с посещаемостью 30К уников. файловый кеш работал хуже, чем мускуль. так-что все индивидуально.

ТСу я бы посоветовал просто попробовать все преоженые варианты.

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

на слабой тачке мускуль будет себя хуже вести чем файловый кеш, на мощной железяке - наоборот.

Внесу и свою лепту чуток :)

Есть еще такой подход: обновлять кеш именно тогда, когда

это необходимо.

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

Например, на сайте есть раздел "новости", "форум", "каталог товаров". На главной странице показывается лента новостей, рубрикатор товаров и статический (неизменяемый) контент, а по всему сайту сквозняком блоки "новости", "свежие темы с форумов".

Тогда при кешировании страниц сайта вводим следующие соответствия (страница - теги):

Главная страница - news, rubrics

Страницы рубрикатора товаров - news, rubrics, forum

Страница конкретного товара (id: 234) - news, forum, tovar234

Задача по управлению кешированием заключается в реализации алгоритма: при добавлении новости очистить кеш от всех страниц с тегом news, при изменении рубрикатора - страницы с тегом rubrics, при изменениях информации о товаре id: 234 - tovar234

Это в теории :)

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

Из плюсов: пользователь всегда видит "свежий" контент, т.е. применение алгоритма оправдано тогда, когда "кровь из носа" нужно отдавать актуальную информацию.

В принципе, неплохие идейки уже по кэшу подкинули... ;)

Думаю, самое время подумать и о тяжеловесных запросах? В чём их тяжеловесность? в количестве записей в результате? или во времени выполнения? или и в том и другом?

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

Простой пример, если вам часто приходится делать выборку из таблицы, в которой достаточно много записей и требуется сортировка выборки, например по названию. А сортировка как известно, очень хорошо грузит базу... То по крону или уж ещё как, можно подготавливать точно такую же таблицу но с уже отсортированными данными! Тогда при выборке ничего сортировать уже не нужно будет. Выигрыш офигительный. Пользовался таким подходом не однократно. Ну а в кипе с кешированием файлов хуже стать не должно ;)

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

Можно сделать бемона, который каждые 12 часов пересчитывает весь кеш (присловутый апдейт, как у яши...). Запуск программы по таймеру.

Кроме этого, можно подготовить выборки из базы, которые чаще всего необходимы и сложить в виде результата.