Костыль - это по определению сложноподдерживаемое, нелогичное решение. Если требования отдавать "честные" данные в бизнесе отсутствуют, то ttl никак не костыль. Он не отрицает "всегда валидных" кэшей. Просто это разные требования к актуальности, которая, ктстати, достигается дополнительным кодом.
Нет? Почему?
Ну во-первых подобная бизнес логика вряд ли поменяется. Через полгода прибежит заказчик и скажет, что он решил честно показывать количество онлайн пользователей, ибо "написано 503, а на самом деле 490"?
Ну так include шаблонов в руки - пусть шаблон будет один
В более-менее серьезных сайтах кэширование происходит на нескольких уровнях, т.к. условия разные. Один multiget к memcache сделать дешевле, чем 10 подзапросов, через nginx+SSI.
Действительно. Давайте создадим разные реализации кеширования. Один в шаблонах с TTL, другой в мапере с обновлением на апдейте... еще осталось парочку придумать, что бы потом сказать - во, смотрите тут сколько кешей, огого.
Поменяться - может и не поменяется, а вот новая добавиться - запросто может. А далее - см п.1
Ну-ка тут поподробнее. Мы говорим о кеше с актуализацией на апдейте данных. Для этого нам нужно знать - какие данные были использованы при генерации этого вот куска хтмл-я. Не, конечно можно в шаблоне это еще одним вызовом куда-то приписать, получить, и т.д.... т.е. я знаю, что лимбовцы любят активные шаблоны, но не до такой же степени
Ага, и не дай бог потребуются данные в разном виде. Ничо, еще какой-нибудь костыль в шаблонизатор прикрутим
)На самом деле этих уровней не так уж и много, если мы говорим о MVC по крайней мере. Сырые данные кешировать... можно, но база обычно сама это неплохо делает. Полученные объекты - да, можно кешировать. Резултаты сложных рассчетов в контроллере... можно, конечно, напрмую класть в кеш, а можно обернуть в те же объекты - там уже все есть. Ну и готовый HTML. Несомненно, может быть специфика - как и в применении любого паттерна, но в большинстве случаев все укладывается в кеширование выхода и кеширование внутренних объектов.
В случае полного кеша - один мультигет - это запрос в PHP, а далее проходим роутер, контроллер, шаблонизатор... 10 SSI - это 10 запросов по файловой системе не уходя с уровня nginx. Файлы можно и в память положить, если так хочется, и в мемкеш - это уже вторично. Так что дешевле - один тяжелый запрос в PHP или 10 легких запросов по файлам?
Что значит добавится новая логика? Добавиться к чему? На пальцах: У нас есть блок, например, новые статьи, и заказчика устраивает отставание на минуту. Мы добавляем 2 строчки и он кэшируется. Если, вдруг, заказчик почему-то меняет свое решение, то мы удаляем 2 строчки и делаем либо кэширование данных, либо оборачиваем это в какую-то абстракцию, которая содержит и удаление и html. Т.е. то, что предлагаешь делать сразу, мы делаем только когда это ДЕСТВИТЕЛЬНО необходимо.
Лимбовцы обычно УДАЛЯЮТ кэш, в тот момент, когда он перестает быть валидным. Заранее генерировать кэш не обязательно, можно dog-pile по разному обходить.
Ага, главное таблички не обновлять
У меня два фронта - мне застрелиться?
Зачем же, FC с корзиной. Для тех кто попроще - придумали и другие варианты шаренных ФС. Да и из мемкеша nginx давно умеет брать. Суть одна - запрос на бекенд очень дорогой.
Дело в том, что кеш перестает быть валидным в момет изменения данных. А TTL - это некое допущение, сколько времени мы разрешаем себе показывать пользователям старый невалидный кеш. А апдейт или удаление - это уже второй вопрос вообще к текущему отношения не имеющий. Удаление, соглашусь, гораздо более удобно в плане _универсальности_.
На пальцах - допустим, у вас не говнокод. У вас данные мапятся через одну дырку, которую можно эти данные легко научить кешировать. Вопрос - зачем вот все вышеописанное, если можно изначально было кешировать данные там? Давайте по плюсам-минусам.
<? if( block( 'block_name' ) ) { ?>
<!-- содержимое блока -->
<? } endBlock( 'block_name' ); ?>Берем один сервер. Смотрим, сколько он может обслужить PHP запросов как выделенный бекенд и мемкеш запросов как выделенный мемкеш сервер. Получаем нужный результат.
<? if( block( 'block_name' ) ) { ?>
<!-- содержимое блока -->
<? } endBlock( 'block_name' ); ?>