DorBer 18 янв 2008 в 10:37

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

2 мин

Комментарии 60

clops 18 янв 2008 в 10:44

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

DorBer 18 янв 2008 в 10:55

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

Setti 18 янв 2008 в 12:12

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

DorBer 18 янв 2008 в 12:38

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

SilenceAndy 18 янв 2008 в 10:47

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

DorBer 18 янв 2008 в 10:52

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

528depp 19 янв 2008 в 11:20

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

DorBer 19 янв 2008 в 21:18

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

davojan 21 янв 2008 в 16:37

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

DorBer 21 янв 2008 в 16:56

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

НЛО прилетело и опубликовало эту надпись здесь

DorBer 18 янв 2008 в 11:58

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

НЛО прилетело и опубликовало эту надпись здесь

DorBer 18 янв 2008 в 13:05

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

DorBer 18 янв 2008 в 13:11

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

MOVe 18 янв 2008 в 10:51

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

DorBer 18 янв 2008 в 10:56

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

evilbloodydemon 18 янв 2008 в 10:52

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

DorBer 18 янв 2008 в 10:58

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

НЛО прилетело и опубликовало эту надпись здесь

DorBer 18 янв 2008 в 11:53

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

НЛО прилетело и опубликовало эту надпись здесь

DorBer 18 янв 2008 в 12:48

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

rimmer333 18 янв 2008 в 12:02

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

DorBer 18 янв 2008 в 12:44

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

tilarids 18 янв 2008 в 14:05

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

DorBer 18 янв 2008 в 14:44

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

crash 18 янв 2008 в 16:38

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

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

НЛО прилетело и опубликовало эту надпись здесь

AirWorker 18 янв 2008 в 22:25

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

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

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

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

d1m 19 янв 2008 в 04:02

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

centur 19 янв 2008 в 07:08

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

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

DorBer 19 янв 2008 в 14:04

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

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

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

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

davojan 19 янв 2008 в 09:55

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

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

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

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

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

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

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

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

Santacruz 19 янв 2008 в 10:52

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

davojan 19 янв 2008 в 11:15

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

Santacruz 19 янв 2008 в 11:19

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

528depp 19 янв 2008 в 11:35

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

528depp 19 янв 2008 в 11:39

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

cloud 19 янв 2008 в 10:29

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

DorBer 19 янв 2008 в 14:05

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

Santacruz 19 янв 2008 в 10:43

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

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

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

Santacruz 19 янв 2008 в 10:47

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

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

KAndy 19 янв 2008 в 11: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

Honeyman 19 янв 2008 в 12: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 19 янв 2008 в 12:41

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

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

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

maxcom 19 янв 2008 в 13:18

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

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

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

Urevic 19 янв 2008 в 22:17

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

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

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

Bonch 19 янв 2008 в 22:42

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

DorBer 20 янв 2008 в 00:15

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

Maximark 21 янв 2008 в 15:10

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

DorBer 21 янв 2008 в 16:46

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

DorBer 21 янв 2008 в 16:47

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

Maximark 22 янв 2008 в 07:22

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

Kuzma 6 фев 2008 в 11:55

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

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

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

DorBer 6 фев 2008 в 12:24

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

iniweb 16 фев 2008 в 21:28

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

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

DorBer 17 фев 2008 в 09:38

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

DorBer 17 фев 2008 в 09:40

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

dmmd 28 мар 2008 в 23:16

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий