DorBer Jan 18 2008 at 13:37

MVC и кэширование

2 min

3.9K

Comments 60

clops Jan 18 2008 at 13:44

я использую своего рода pull технологию – то бишь VIEW говорит контроллеру «вах, у меня тут кое-что кажется не из кеша – давай ка обновим»... правда в этом меня спасает кеш-блоки смарти, где в шаблоне можно указать какие блоки стоит кешировать а какие нет (и как долго). Например те же облака тегов и прочую лабуду я пересчитываю не чаще чем раз в час.

DorBer Jan 18 2008 at 13:55

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

Setti Jan 18 2008 at 15:12

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

DorBer Jan 18 2008 at 15:38

Смарти есть, но структура ядра такова, что нельзя без проблем кэшировать его средствами. Местами я сделал обертки на его кэш и это прошло, но осталась проблема с MVC описанная в топике

SilenceAndy Jan 18 2008 at 13:47

Я возможно плохо разбираюсь в серверном программировании, но по моему вам нужен memcache.

DorBer Jan 18 2008 at 13:52

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

528depp Jan 19 2008 at 14:20

Ошибаетесь, memcached не использует форк. Он использует threads. Его главное приемущество в том что на нем можно построить распределенную систему кэширования -> на нескольких серверах. Тоесть если есть предположения что проект будет расти, то это подходящая технология.
Вобще советую вам более пристально глянуть. После того как facebook стал использовать memcached они очень хорошо его оптимизировали.

DorBer Jan 20 2008 at 00:18

Все зависит от способа установки php, в моем случае он форкает...

davojan Jan 21 2008 at 19:37

А php тут причём? Может вы не о memcached говорите?

DorBer Jan 21 2008 at 19:56

...не знаю. че-то устал я. может путаю.

UFO just landed and posted this here

DorBer Jan 18 2008 at 14:58

Это кэширование "компилированного" php-кода, т.е. меньше работает интерпритатор php, но к кэшированию данных они не имеют отношения. В моем случае время компиляции - капля в море по сравнению с выборкой и обработкой данных. Но в плане eaccel есть при переезде на другой сервак через две недели.

UFO just landed and posted this here

DorBer Jan 18 2008 at 16:05

О, да, спасибо! С этой стороны я их не рассматривал, узнал много нового...

DorBer Jan 18 2008 at 16:11

Хотя главный вопрос топика пока еще открыт...

MOVe Jan 18 2008 at 13:51

На 5 шаге и нужно кэшировать данные — «Создать и записать html в файл».
Но! Если у Вас модульная система, то необходимо кэшировать каждый модуль в отдельности, так как вся информация одновременно вряд ли поменяется, а информация в отдельных модулях может меняться с разной периодичностью.

DorBer Jan 18 2008 at 13:56

Спасибо, но вы просто резюмировали несколько последних абзацев.
Может опишите поподробнее что имели в виду?

evilbloodydemon Jan 18 2008 at 13:52

я бы посмотрел исходники mvc-фрэймворков, там точно есть

DorBer Jan 18 2008 at 13:58

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

UFO just landed and posted this here

DorBer Jan 18 2008 at 14:53

В моем случае информация обновляется через 1-2 минуты, но с выводом можно подождать до 10 минут, так что мне хватает по времени.
Кстати, отслеживание обновления информации можно повесить на триггеры БД, если вдруг интересно.
А вот по поводу многих моделей - да, это выход, но мне кажется это уже какой-то странный мвц выходит... Конечно, две головы лучше, но мне кажется пропадает весь смысл... Хотя вам может и виднее

UFO just landed and posted this here

DorBer Jan 18 2008 at 15:48

Мне кажется это уже не совсем MVC получается. Не возникает проблем с обновлением кода? Я бы если использовал несколько моделей, то для подмены друг друга, а не для совсместного использования. Может я просто не понимаю конкретную задачу и метод ее решения... :) Подумаю на досуге. Спасибо

rimmer333 Jan 18 2008 at 15:02

Шитов в свое время подумал на эту тему: http://www.artlebedev.ru/tools/technogre… . И Золотухин приложился: http://www.artlebedev.ru/tools/technogre…

DorBer Jan 18 2008 at 15:44

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

tilarids Jan 18 2008 at 17:05

Например, джанга к делу кеширования подходит так: http://www.djangoproject.com/documentati…

DorBer Jan 18 2008 at 17:44

Нужно смотреть код, как они кэшируют именно в приложении к MVC.
В статье просто описаны возможности системы по кэшированию.
Моя основаня проблема в данном вопросе состоит в том, что я не могу переписать весь код существующей системы, но могу писать дополнительные обертки для уже готового функционала. Именно поэтому я пытаюсь найти неординарные подходы.
За ссылку спасибо, уже кое-что подсмотрел для своих будущих проектов.

crash Jan 18 2008 at 19:38

В Джанге бы это решилось так: есть у неё сигналы на PyDispatcher, и есть такой сигнальчик post_save который срабатывает при сохранении модели. Я вешаю на такие сигналы свою функцию, которая смотрит что за модель сохранили и обновляет её кеш.
Это штука обзывается еще каким-то паттерном, но я забыл название.

Думаю в вашем случае может пригодится :)

UFO just landed and posted this here

AirWorker Jan 19 2008 at 01:25

Палю свое решение:

HTML-страница представляет собой иерархию объектов конкретных HTML-блоков. (Верхний объект инкапсулирует объекты вложенных блоков). Объекты HTML-блоков умеют сами себя кешировать. Метод getContent() возвращает HTML, при этом проверяется кеш. Если попадание - вернуть HTML, промах - отрендерить HTML, запросив модель, сохранить в кеше и вернуть HTML.

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

Все очень быстро и довольно просто. Проверено в нескольких проектах.

d1m Jan 19 2008 at 07:02

При переходе на рельсы увидел кеширование, но пока не разобрался с ним.
Весьма просто и доступно нашел тут:
http://www.railsenvy.com/2007/2/28/rails…
http://www.railsenvy.com/2007/3/20/ruby-…
С выходом rails2 появилось еще больше возможностей - как, например, кеширование sql-запросов, роутов.

centur Jan 19 2008 at 10:08

А Вам действительно именно нужно навесить кэширование ? Просто кэширование, особенно "неординарные пути" - техническая задача. А окончательный итог обычно - решение пользовательской проблемы. Вы точно уверены что пользовательскую проблему решит именно кэширование html кода ? Может задачу а-ля "у нас сайт тормозит, нужно ускорить" позволит решить более быстрая кодогенерация html, генерация более компактного html (например, буквально недавно "решали" задачу - сайт выдавал среднюю страницу на 2мб, кодогенерация в asp.net все-таки далека от "вменяемо оптимальной", уменьшили до 800 кб - стало гораздо комфортнее (работа идет по LAN) ) или опять же кэширование данных? Просто мне кажется не так тривиально к MVC прикрутить кэширование именно html, учитывая что сам паттерн предполагает при изменении модели - изменять вью, а вы будете выдавать его из кэша...

Например мы в проекте реализуем MVP, а не классический MVC. В этом случае все данные идут всегда от презентера (нету связи View-Model). На данный момент у нас основной упор по производительности - извлечение данных из БД (много и разных, по разным правилам) - в таком случае основное место кэширования - DAL слой, т.е. классы, которые извлекают непосредственно данные из БД. Кэшировать HTML из-за большого количества подгружаемых вещей (ajax) и сложного UI с состояниями особо не имеет смысла. К тому же у пользователей совершенно разные страницы - у каждого свой набор данных

DorBer Jan 19 2008 at 17:04

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

Осталось кэшировать именно html.

Просто мне кажется не так тривиально к MVC прикрутить кэширование именно html, учитывая что сам паттерн предполагает при изменении модели - изменять вью, а вы будете выдавать его из кэша...

Вот именно, в этом и проблема :)

davojan Jan 19 2008 at 12:55

Есть одна идея, которая очень хорошо будет кэшировать, но довольно сложна в реализации:

Допустим есть такой урл: http://www.example.com/product/list.html
Понятно, что это экшн list контроллера product.

Когда мы первый раз обращаемся по этому урлу, то работает скрипт, и по мере формирования страницы нужно каким-то образом сохранить все зависимости для данного урла. Результат работы вьюхи записываем в файл /product/list.html в корне веб-сервера.

В следующий раз, когда произойдёт обращение по этому урлу, то веб-сервер просто отдасть этот статический файл, и не будет даже запускать скрипт.

В метод save() у модели нужно внедрить некий код, который будет удалять все файлы, которые зависят от этой модели (зависимости были записаны раньше)

При очередном обращении к урлу, когда веб-сервер не найдёт файл, нужно навесить на обработчик 404-ошибки запуск скриптов

Примерно так...
Самое сложное - правильно записать зависимости, чтобы обновлялись только те файлы, который действительно должны измениться. Ведь зависимость может быть не только от одного какого-нибудь экземпляра модели, но и от какого-нибудь набора, который может измениться, например, в зависимости от текущего времени.

Надеюсь, понятно изложил. Не знаю, насколько это Вам подойдёт.

Santacruz Jan 19 2008 at 13:52

true.. а теперь как сделать dynamic? Твой /product/list.html и мой /product/list.html будут разные, например User_Id разный.. Под Каждый Юзернейм делать кеш? (я так думаю)

davojan Jan 19 2008 at 14:15

Ну да, по этой схеме получается так. Юзер в данном случае является зависимостью.
Но если отличия несущественные, то можно схитрить: сначала загрузить всю страницу, а потом по ajax'у загрузить отличающийся кусок. Например: имеем дело с интернет-магазином, в котором юзер ещё не залогинился, но может набирать корзину. На каждой странице показывается примерно следующее: "в вашей корзине X товаров на XXXXX рублей", а всё остальное - для всех одинаково. Грузим сначала статическую страницу из кэша, а на document.ready загружаем данные из сессии (сколько и сумма) и показываем.

Santacruz Jan 19 2008 at 14:19

прокатит. выплевывать кеш. а те места где надо брать real time выносятся на ajax.
Вроде дело в шляпе.

528depp Jan 19 2008 at 14:35

Это напоминает технологию SSI

528depp Jan 19 2008 at 14:39

Опс, извиняюсь, немного не вьехал.

cloud Jan 19 2008 at 13:29

У меня кэширование идет на уровне модели, и кэшируются непосредственно данные.
Кэшировать html- хлопотно, так как он может различаться от пользователя к пользователю, кроме того у меня одни и те-же данные могут отдаваться в html и xml и в json- а узкое место именно доступ к бд.
Актуальность кэша- либо по времени жизни, либо через принудительное разрушение при обновлении (http://wiki.toukmanov.ru/dbSelect - тут подробнее, если интересно)
На каких-нибудь очень нагруженных страницах- вешаю тупой кэш html, отдаваемого модулем.

DorBer Jan 19 2008 at 17:05

Кэширование данных уже есть

Santacruz Jan 19 2008 at 13:43

Народ не въехал в топик.

Вот мысль кешировать MVC, но это только для static. В конце action добавляется элемент в массив с ключем URI а значение уже сам придумай.. Перед тем как инициализировать MVC надо посмотреть в массив.

Сейчас думаю как сделать для всего остального

Santacruz Jan 19 2008 at 13:47

http://habrahabr.ru/blog/q2a/34186.html#…

вот товарищь уже дельное что то предлогает

KAndy Jan 19 2008 at 14:06

как по мне решается так:



class CachePage{

   protected _cache = true;

 function __construct(){

   ob_start()

 }

function Run(){

   $this->_cache = $this->_isCache();

   if ( $this->_cache){

      echo $this->getCache();

   }else{

    include 'index1.php'; // old index.php

   }



}



function _isCache{

   return ... {  $GET['cache'] != true }

}

 function __destract(){

     $cont = ob_get_content();

     $this->setCache($cont);



}

это пример...

Проще Zend_Cache

-1

Honeyman Jan 19 2008 at 15:01

Очень рекомендую посмотреть, как кэширование логически реализовано в Django (http://www.djangoproject.com/documentati…).
Вкратце - там есть API как для низкоуровневого кэширования (любых объектов, задавая их имя), так и для кэширования отдельных Django views. А вот уже для каждого view, в Джанго выбирается, на какой срок он кэшируется; ну, и другие нюансы реализации, наподобие "The cache middleware caches every page that doesn’t have GET or POST parameters", и т.д.

korchasa Jan 19 2008 at 15:41

"Красивый" способ реализовать частичное кеширование из представления только один pull-подход. Иначе придется в модель пихать проверки на наличие кеша. В принципе и это не страшно, если вы используете view, как valueObject, и кешируете именно его.

Но в таком кешировании практически нет необходимости, если вы используете адекватный шаблонизатор, с быстрой фазой execute. В вашем случае гораздо проще, ИМХО, кешировать данные.

ЗЫ: Честно говоря не очень понимаю, откуда в смарти взялся pull. Пойду копать ;)

maxcom Jan 19 2008 at 16:18

По идее кеширование должно быть двухуровневое - и в модели, и во view

Модель кладет в кеш свою последнюю версию в сериализованном виде. При использовании сначала извлекается версия из кеша, проверяется ее актуальность и используется либо она, либо создается новая из БД (и обновляется в кеше).

Кеширование view осмысленно делать прямо в HTML-виде с коротким временем хранения без валидации как таковой - это на случай частых запросов одного и того-же

Urevic Jan 20 2008 at 01:17

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

Мне кажется действительно лучше посмотреть на APC и eAccelerator и с их помощью хранить кэш данных в памяти. Плюс это, по идее, должно ускорить генерацию html, за счет кэширования опкода. Короче, будет красиво и точно быстрее, чем сейчас.

Если этого будет мало, можно еще посмотреть, может какие-то страницы можно эффективно кэшировать целиком - это вроде проще положить на MVC красиво.

Bonch Jan 20 2008 at 01:42

А попробуйте дополнительно кэшировать на стороне клиента. Я думаю это неплохая идея.

DorBer Jan 20 2008 at 03:15

Да, мы уже смеялись с коллегами. Про гугл джеарс слышали? Мы в шутку обсуждали возможность заливки на клиента десятка метров каталога одного сайта :) Зато сервак будет свободен :)

Maximark Jan 21 2008 at 18:10

Прочитать все комменты - не осилил...времени нет - пишу cmf (95% выполнено, уже даже работают сайты на cmf (скорее cmf чем cms? потому как сущность я переложил на плечи сис админов а не программеров и в довольно легкой, понятливой форме)
и mvc как обычно рулит...
Всё конечно зависит от архитектуры, если архитектура унифицирована (не в коем случае не путать с нормализированными данными, потому как данные скорее денормализированные...но они Унифицированы (мода такая если кто железо знает вспомнит про блоки шейдеров в видеокартах)) и есть иерархическая БД, отделенная от иерархии (во сложил :) ), данных и описаний (указателей) на обьекты, то можно сделать так.
Так как унификация рулит, то кешировать поблочно. Соотвественно контроллер должен обрабатывать блок и вызывать модули обработки - отсюда - кешируем попросту строку "запроса"... т.е. при такой архитектуре... есть модуль подготовки запроса... переводим подготовленный запрос в md5 потом результат запроса в хранилище кеша с блоком / номером id контроллера / md5 имя файла - сериализованный результат...
Что выигрываем ... при изменении даже прав доступа (при иерархии это легко и в запросе делать) будет изменяться строка запроса, соотвественно браться только нужный результат.
Сумбурно конечно написал, если кому интересно могу поподробнее... про новую (как я считаю) технологию разработки cmf php & mysql
Вообще-то посоветовали написать статью про унифицированные иерархические БД... напишу обязательно, когда закончу проект.
Кстати кто хочет присоединиться к проекту очень было бы неплохо.
В 2 словах Drupal и Joomla (тем более) уже по архитектуре отдыхают, получилась очень гибкая, быстрая и равномерно нагружающая сервер система.

DorBer Jan 21 2008 at 19:46

Да, я вас понял. Подобный способ я применяю для редко меняющихся тяжеловесных структур данных, связанных с большими затратами на выборку и обработку (обычно бинарные деревья).

DorBer Jan 21 2008 at 19:47

open source? коды не дадите посмотреть? ;)

Maximark Jan 22 2008 at 10:22

GNU GENERAL PUBLIC LICENSE
Сейчас рефакторю... код сырой, можно в принципе и показать даже сырой.
В pm ...

Kuzma Feb 6 2008 at 14:55

Отличное получилось обсуждение. С интересными идеями. Спасибо. Но...

Цитата:
> (крупный региональный портал), код которого переписать
> полностью нет возможности (по множеству причин).
> Необходимо на уже готовый функционал навесить
> возможность кэширования.

Насколько я понимаю, у портала проблемы с нагрузкой на сервак.
на мой взгляд, проще и быстрее (а, возможно, и финансово выгоднее) будет поменять железо на серваке.
Увы, но идеальных систем не бывает =/

DorBer Feb 6 2008 at 15:24

Куплен новый сервак, очень так нифиговый. Скоро ожидается переезд, но с таким ростом кол-ва посещний думаю не надолго поможет... У меня уже есть хорошая идея по кэшированию, но ее реализация связана с достаточным количеством модификаций кода. Надеюсь, что скоро руководство портала все-таки примет решение о модернизации движка, работающего аж на PHP4 :)

iniweb Feb 17 2008 at 00:28

Использую этот класс (Переписал совсем чуть чуть): http://larin.in/archives/21

Даволен как слон, закэшировал всё что только можно :)

DorBer Feb 17 2008 at 12:38

Это реализация кэша, но к MVC она никак не относится... :)

DorBer Feb 17 2008 at 12:40

Хотя кое-что верно :) Я уже решил как оно должно быть, проверю, напишу статью

dmmd Mar 29 2008 at 02:16

Поставлю-ка я здесь ссылку на свою статью: Фрагментарное кэширование в MVC веб-фреймворках

Show the best of all time