Итак.
Начнем с самой затеи кэшировать блоки html-я, как огромного ограничителя - практически не бывает таких ситуаций, когда запрос к одной модели соответствует одному блоку шаблона и никак не влияет на другой. Огранизовать зависимости здесь будет очено сложно, или вообще невозможно.
Более того. В итоге ты можешь получить вовсе не оптимизацию, а пессимизацию. Вот возьмем для примера этот форум. На каждой странице есть множество блоков, зависящих от того, авторизован пользователь или нет, а также от его уровня доступа (модератор, админ...). Пока все блоки лежат в кэше, вроде бы, все выглядит неплохо - но надо не забывать, что SSI - это подзапрос, который, во-первых, не такая уж и легкая штука, а во-вторых, на каждый подзапрос будет отдельное соединение (хотя это решается модулем upstream keepalive Максима Дунина) и отдельный запрос к memcached - тогда как на уровне приложения можно было бы обойтись одним соединением и одним multiget-ом. А как только мы получили MISS-ы - у нас мало того, что вместо одного запроса к бэкенду их N, да еще и каждый раз - по числу подзапросов - придется повторить общую логику приложения - проинициализировать все дела, проверить, авторизован ли пользователь и так далее.
В итоге, если бэкенд сделать достаточно легким, умеющим в лучшем случае (то есть, везде cache hit) быстро проинициализироваться, сделать multiget, сгенерить html быстрым шаблонизатором и отдать результат, а худший случай за 1 запрос сводит к лучшему
поместив все что надо в кэш - это получается оптимальнее (и ничего придумывать не надо - это уже паттерн)
Так что единственное применение, которое я вижу, - это сборка _независимых_ блоков с отдельных бэкендов (например, главная страница yandex.ru четко делится на независимые блоки) - да и тут гораздо удобнее получать от бэкендов не готовый HTML, а набор данных для template engine, а саму генерацию html делать уже на фронтенде; собственно, так и сделано в яндексе (xscript), и так же можно попробовать сделать на уровне nginx, взяв за основу nginx cttp2 модуль. То есть, если уж переносить что-то на фронт - так это view.
Может показаться, что еще один вариант - это сборка "статических" сайтов, в которых нет каких-то зависимостей между блоками, - скажем, новостной сайт по типу lenta.ru; однако применение для статики memcached не имеет совершенно никакого смысла - отдать статический файл с диска намного быстрее, и тут хватит голого nginx/ssi; если же по каким-то причинам раскладывать статику на фронт неудобно, можно воспользоваться кэшированием в nginx (только надо решить проблему программной условной инвалидации кэша, поддержки которой в nginx пока нет; но тут можно обойтись манипуляциями с генерацией конфига и хитрым cache_key).
Начнем с самой затеи кэшировать блоки html-я, как огромного ограничителя - практически не бывает таких ситуаций, когда запрос к одной модели соответствует одному блоку шаблона и никак не влияет на другой. Огранизовать зависимости здесь будет очено сложно, или вообще невозможно.
Более того. В итоге ты можешь получить вовсе не оптимизацию, а пессимизацию. Вот возьмем для примера этот форум. На каждой странице есть множество блоков, зависящих от того, авторизован пользователь или нет, а также от его уровня доступа (модератор, админ...). Пока все блоки лежат в кэше, вроде бы, все выглядит неплохо - но надо не забывать, что SSI - это подзапрос, который, во-первых, не такая уж и легкая штука, а во-вторых, на каждый подзапрос будет отдельное соединение (хотя это решается модулем upstream keepalive Максима Дунина) и отдельный запрос к memcached - тогда как на уровне приложения можно было бы обойтись одним соединением и одним multiget-ом. А как только мы получили MISS-ы - у нас мало того, что вместо одного запроса к бэкенду их N, да еще и каждый раз - по числу подзапросов - придется повторить общую логику приложения - проинициализировать все дела, проверить, авторизован ли пользователь и так далее.
В итоге, если бэкенд сделать достаточно легким, умеющим в лучшем случае (то есть, везде cache hit) быстро проинициализироваться, сделать multiget, сгенерить html быстрым шаблонизатором и отдать результат, а худший случай за 1 запрос сводит к лучшему
поместив все что надо в кэш - это получается оптимальнее (и ничего придумывать не надо - это уже паттерн)Так что единственное применение, которое я вижу, - это сборка _независимых_ блоков с отдельных бэкендов (например, главная страница yandex.ru четко делится на независимые блоки) - да и тут гораздо удобнее получать от бэкендов не готовый HTML, а набор данных для template engine, а саму генерацию html делать уже на фронтенде; собственно, так и сделано в яндексе (xscript), и так же можно попробовать сделать на уровне nginx, взяв за основу nginx cttp2 модуль. То есть, если уж переносить что-то на фронт - так это view.
Может показаться, что еще один вариант - это сборка "статических" сайтов, в которых нет каких-то зависимостей между блоками, - скажем, новостной сайт по типу lenta.ru; однако применение для статики memcached не имеет совершенно никакого смысла - отдать статический файл с диска намного быстрее, и тут хватит голого nginx/ssi; если же по каким-то причинам раскладывать статику на фронт неудобно, можно воспользоваться кэшированием в nginx (только надо решить проблему программной условной инвалидации кэша, поддержки которой в nginx пока нет; но тут можно обойтись манипуляциями с генерацией конфига и хитрым cache_key).
Особенно на всяких хабрах (что неудивительно).