@lauri5 янв 2009 в 16:00

Анонс и история Explay CMS 3 (Core)

4 мин

1.3K

CMS *

+48

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

@orloff 5 янв 2009 в 16:00

под кат пожалуйста

@lauri 5 янв 2009 в 16:05

спасибо, исправился :)

@Novikov 3 мар 2009 в 20:49

Из под ката, пожалуйста.

@crackos 5 янв 2009 в 16:27

Анонс и исторя

А в заголовке-то буковку «и» забыли :)

@lauri 5 янв 2009 в 16:30

спасибо, представляю что в коде :)

@romnovi 5 янв 2009 в 16:38

>Например, у нас 100 комментариев к статье (100 запросов + 1 некешируемый на выборку списка id)
Жесть… 1 запросом никак не получиться?

@lauri 5 янв 2009 в 16:43

В кеше лежат отдельные объекты, а при выборке одним sql-запросом мы не знаем какие объекты закешированы, а какие нет — теряется смысл кеша.

@romnovi 5 янв 2009 в 16:54

>а при включенном — минимум 1
>При изменении одного комментария модератором — минимум 2

Дык всё равно будут запросы к базе будут, я бы не парился и выбирал бы 1!

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

@RomanL 5 янв 2009 в 19:20

Ой не факт…
Подобная стратегия работает хорошо если у вас памяти под кэш немеряно, да и то… очень уж разные ситуации бывают и жёстко оставлять только один вариант — могут быть большие проблемы.

@smart 5 янв 2009 в 21:35

Памяти под кеш всегда «немеряно» — память очень дешевая, мемкеш очень легко масштабируется. Обычно в это не упирается. А вот в количество запросов (по 1 на каждый комментарий) — как раз можно и упереться.

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

@lauri 5 янв 2009 в 17:48

Считаю это правильнее, нежели писать шаблонизатор на шаблонизаторе. Тем более возможно прикрутить тот же Smarty.

@duke_nu 6 янв 2009 в 12:11

странно, если вы к пхп относитесь как к шаблонизатору, почемы вы до сих пор, пишите на нем подобные проекты. =)

@NewStoic 5 янв 2009 в 17:19

ничего не понял… отличие от старой версии только во внутренностях?

@zaartix 5 янв 2009 в 17:40

старая еще и работала, а эта пока не совсем :)

@NewStoic 5 янв 2009 в 18:16

да, я тоже мучаюсь — никак не могу заставить работать уже битый час =)

@Devgru 5 янв 2009 в 18:37

это отнюдь не ужасно :)

@surething 5 янв 2009 в 17:21

> Архитектура движка не позволяет выбирать несколько объектов одним запросом к БД — для каждого объекта свой запрос.

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

@lauri 5 янв 2009 в 17:59

Я бы с большим интересом послушал об этом :)

@surething 6 янв 2009 в 00:05

хмм. позырил код в транке и то, что там есть сейчас — не для простых людей. не смог я полностью разобраться во всех таблицах этого «объектного» хранилища. но название класса «Object» очень понравилось :)
когда будет документация, мне кажется, можно будет что-то посоветовать в плане кеширования на уровне БД.

кстати, хорошая модель контент-репозитария у системы ez publish ( ez.no/doc/ez_publish/technical_manual/4_0/concepts_and_basics/content_management/datatypes ) у меня однажды был такой классный велик для хранения контента, а она мне все колеса отшибла ;-)

@kostin 5 янв 2009 в 17:30

Вы молодец! Хватило хотя бы даже и того, что вы проект не бросили до сих пор, чтобы порадоваться.

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

@Barttos 5 янв 2009 в 17:35

Обязательные:
…
mb_string
…

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

@Foror 5 янв 2009 в 17:39

Думаю дальше ужаснешься от текущий архитектуры и начнешь использовать фреймворки. Узнаешь про паттерны. А дальше может и python или ruby начнешь смотреть. Это нормально, главное не зацикливайся на каждом уровне больше 4-6 месяцев.

P.S. А много абстракций ни к чему хорошему не приводят. По крайне-мере на производительности это отражается в худшую сторону.

@lauri 5 янв 2009 в 17:52

Не сочтите за завышенную самооценку, но про паттерны и фреймфорки я знаю, а паттерны еще и умудряюсь применять. Про Python & Ruby спорить не буду, но мне пока PHP & C++ хватает :)

@lauri 5 янв 2009 в 17:57

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

@smart 6 янв 2009 в 00:47

До определенного предела это окупается. Но по мере роста нагрузки становится выгоднее оптимизировать код, чем покупать железо. Представьте себе масштабы Яндекс или vkontakte, например.

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

@lauri 5 янв 2009 в 17:44

Вам теперь надо XSLT к PHP подключить

@el777 5 янв 2009 в 21:57

[offtop]
> Fatal error: Class XSLTProcessor or him interface not found!
А почему «him»? Если я правильно понимаю, то «its» или хотя бы «his»?[/offtop]

@SenSoft 5 янв 2009 в 17:48

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

@lauri 5 янв 2009 в 17:54

Велосипед — да, зато есть чем гордится и к чему стремиться :)

@gigimon 5 янв 2009 в 17:55

Прочитав статейку, подумал что вы написали не CMS, а фреймворко-CMS

@lauri 5 янв 2009 в 17:58

На данный момент так и есть. CMS с админкой будет дальше.

@egoholic 5 янв 2009 в 17:58

Спасибо вам за старания, надеюсь, новая, 3 версия будет много лучше предыдущей. Удачи вам!

@LDEV 5 янв 2009 в 18:06

Ну что ж, будем следить за развитием! Текущие ветки совсем забросил? Err 500 частенько падает на текущих сайтах…

@lauri 5 янв 2009 в 18:09

Да, и в админку сервера доступа нет =\

@LDEV 5 янв 2009 в 19:02

Это к Александру :)

@neuymin 5 янв 2009 в 18:56

:-) Двигайся дальше.

@Shedar 5 янв 2009 в 19:02

> CMS ориентирована на создание социальных сетей и интернет-сообществ, то кеширование — это все
Несколько вопросов.
1. Есть какие-то замеры? Например типичная простая страничка 10 объектов (начала статей), листалка, навигация. Или же статейка с комментариями. На каком железе сколько запросов обрабатывается без кэша и сколько с кэшем в секунду. Например устроив стресс тест с помощью http_load.
2. Как определяется что попадает в кэш а что нет? Заносить все — памяти у серверов много, но в пределах разумного =) А если не все объекты в памяти не держать, то с базой желательно работать более-менее оптимально
> лучше потратиться один раз на мощный сервер
все понятие относительное. говорить о удачности или неудачности того или иного решения можно когда есть числа, а не обсуждая сферического коня в вакууме. Например, сталкивался с системой, написаной очень модно, но обрабатывающей два запроса в секунду на четырехядерном сервере, что на мой взгляд ни в какие ворота.

@Covex 5 янв 2009 в 19:28

> Синтаксис: {{имя_модуля:: название_метода(параметры)}}.
>… но он явно быстрее подгрузки XML-таблиц прямо в XSLT через document()

А это действительно на существенно быстрее?

PS Кстати, Explay3 на UMI.CMS чем-то похожа (как мне показалось)

@myfeelings 5 янв 2009 в 20:03

PS Кстати, Explay3 на UMI.CMS чем-то похожа (как мне показалось)

Может, потому что lauri работает(или работал) над umi?)

@lauri 5 янв 2009 в 20:06

Ваша правда :)

@lauri 5 янв 2009 в 20:10

поправочка — все-таки работал

@Covex 5 янв 2009 в 20:10

Вот ведь, а =)
А я думал, что заговор раскрыл. Отбой =)

@lauri 5 янв 2009 в 20:09

Быстрее: в тойже ЮМИ в XSLT шаблонах везде обращение к сайту через document(), при этом куча времени уходит на генерацию запрашиваемой страницы, а в случае Explay время отработки макроса — это только лишь время работы вызываемого модуля.

@Covex 5 янв 2009 в 20:21

Жаль. Мне идея с document() очень понравилась… Надо будет замеры какие-нибудь сделать.

@lauri 5 янв 2009 в 20:43

Document(), как родной способ, будет, конечно, красивее, а макросы в XSLT — это, к сожалению, костыль. Возможности движка позволяют использовать оба способа, достаточно вызвать необходимую страницу с расширением xml.

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

@Sannis 5 янв 2009 в 20:20

Напоминает Drupal, лет этак 5 назад, да? :)

@lauri 5 янв 2009 в 20:44

Я с друпалом дела не имел. Он 5 лет назад был на ООП?

@Sannis 5 янв 2009 в 21:28

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

@chaosty 5 янв 2009 в 21:53

он и сейчас не ооп ))

@Sannis 6 янв 2009 в 20:24

Для вас ООП — это классы?

@alfa 5 янв 2009 в 20:50

lauri Все без исключения методы уже комментированы для дальнейшего составления документации.

doxygen в помощь и ничего не надо писать ручками, если комментированы по правилам.

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

@lauri 5 янв 2009 в 21:29

А где у Юмисофта 3-ка? 0_о

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

@lauri 5 янв 2009 в 21:58

Начнем с того, что фирменного стиля Вы еще не видели и не надо строить предаоложения, что это будет синий, немного эпполовский, дизайн. Во-вторых, я уважаю труд разработчиков Юмисофта и я бы не стал пи… их труд, хотя бы по этой причине. Никто в веб-разработке за последниие 3-5 лет не изобретал ничего революционно нового =) Подумайте, прежде, чем обвинять кого-либо в пи…

@descentspb 5 янв 2009 в 21:52

Для меня интерес представляла ваша структура БД, просто для ознакомления, так как, судя по описанию, я предположил, что она достойна того, чтобы на нее взглянуть. Просматривая sql-файл, вспомнилась проблема, с которой я недавно столкнулся при проектировании. Похожая проблема на stackoverflow. Архитектура БД, конечно, разная, но суть в негативном отношении профессионалов к применению метода Entity-attribute-value.

@homm 5 янв 2009 в 21:54

Насчет кеша.
Один запрос будет быстрее, чем 100 обращений к memcached, тем более к диску.
Мне нравится такая схема: в самой таблице с объектами (как вариант в присоединенной, всеже шаблонов на тип может быть несколько) хранится кеш. Выборка айдишников идет вместе с кешем, смотрится если кеш есть — выводится он. Если кеш пуст — вызывается что-то, что кеш заполнит, внесет его в таблицу объектов и отдаст выводу. Лучше сразу после получения кешей определять объекты с промохом, делать на всех один запрос и заполнять кеш тоже одним запросом.

В результате при пустом кеше: 1 запрос легкий, кеш пустой, одни айдишники. 1 запрос тяжелый, скопом собираем всю информацию для всех объектов, которые нужно вывести. Один мощный апдейт.
При полном кеше: один запрос достаточно тяжелый по трафику, но зато в нем уже прямой вывод на страницу.

@lauri 6 янв 2009 в 10:50

Спасибо за отличную идею. В движке еще можно многое изменить, так что я попробую Ваш совет.

@ur001 5 янв 2009 в 22:03

Здорово :) С любопытством слежу за развитием LiveStreet и Explay. После этой публикации ставлю мысленный "+" Explay. Предыдущий код был ужасен поистине… А этот намного-много лучше!

Конечно, запрет «нескольких объектов одним запросом» в пользу кеширования — это смелый ход. Подумаю на досуге насколько он может быть оправдан. На самом деле я сам давно заметил тенденцию упрощения запросов в наших проектах с JOIN-ов на пост-JOIN-ы. Только по 100 элементов мы обычно не выбираем, а используем несколько WHERE id IN ()

@FaStY 5 янв 2009 в 23:33

хм… блин, что-то интерестное… точнее странное… нельзя выбрать например одним запрос много комментов? насколько это оправдано? если так получиться, что кэш уйдет в даун, а на сайте будет около 5000 тем, в каждом по 500 комментариев… это ж скока нужно времени будет первому «счастливчику», который зайдет на сайт… он походу успеет вырастить ребенка и построить дом и посадить дерево… за это время пока ему откроется главная… вообще код клевый, но выборка из базы- что-то нужно с этим делать… неужели нету других вариантов?
P/S а функцией Count можно пользоваться? или подсчитывать нужно по одному объекту?

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

@PingMe 6 янв 2009 в 09:58

explay/classes/i18n.parser.php

/**
* Купить:
* — молоко «Простоквашино»
* — бананы
* — шампунь
* — мыло (жидкое + обычное)
* —!!! масло «Русские кружева»!!!
*/

@Covex 6 янв 2009 в 10:44

Нашёл у вас дырку: example.com/my/__default();var_export($this);die
Давайте незачётку! eval без должной фильтрации запроса до добра не доведёт =)

А ещё: подскажите, пожалуйста, где у вас там находится место, в котором происходят выборки объектов (из кэша, а если нет — из таблиц)

@lauri 6 янв 2009 в 10:47

Как раз в раздумьях про фильтрацию eval'ов, у Вас случайно нет идеи?

Объекты проходят через ObjectsController, в частности ObjectsController::getObject (...);

@Covex 6 янв 2009 в 10:56

Имхо, в каждом отдельном случае должны быть свои проверки.

if (!method_exists($this->modules[$moduleName]['object'], $method)) throw new CoreException (lang('error_controller_module_return_invalid_object','core'));

Ещё можно посмотреть в сторону Reflection

@lauri 6 янв 2009 в 11:44

Спасибо, исправил :) Правда method_exists () тут не обошлось — в модулях можно реализовывать множественное наследование, поэтому пришлось писать свой method_exists ().

@Covex 6 янв 2009 в 12:36

ObjectsController::getObject (...);

Я тут покопался в коде, почитал комменты…

В кеше лежат отдельные объекты, а при выборке одним sql-запросом мы не знаем какие объекты закешированы, а какие нет — теряется смысл кеша.

Именно поэтому вы и не сможете уйти от ста (или тысяч ?) запросов к кэшу/БД.

Имхо:
Вы не то кэшируете. Запись таблицы — слишком маленькая сущность, чтобы быть закэшированной.
Если вы от этого не откажетесь, именно в «социальных сетях и интернет-сообществах» ваши принципы кэширования проявят себя с отрицательной строны. Правда, если откажетесь — придётся всё переделывать.

@homm 6 янв 2009 в 12:47

Имхо, вы не правы. Отдельный объект — это отличная сущность для кеширования, особенно в «социальных сетях и интернет-сообществах», где можно вывести объекты сначала по хранологии, потом по тегам, потом по авторам и по вашей схеме 10 раз пересторить кеш.

@Covex 6 янв 2009 в 12:58

Может быть и не прав.

Отдельный объект — это отличная сущность для кеширования

Но с другой стороны — всё зависит от того, что именно считать за объект!
Что лучше Объект «100 Комментариев» или 100 Объектов «Комментарий»?

@homm 6 янв 2009 в 13:14

Если комментарии древодины — очевидно, что рациональнее второй вариант. Если линейны — первый, причем можно даже кеш не перестраивать, а дозаписывать новыми комментариями.

@romy4 6 янв 2009 в 18:31

В этом случае надо учитывать одну особенность комментариев: отношение между прочитанными комментариями и добавленными. Пускай будет 100:1 (100 раз прочитали, один добавили). Очевидно, что менее накладно будет перезаписать структуру с комментариями, чем каждый раз искать закеширован ли каждый коммент.
И потом, возникает вопрос: в чём тогда ускорение с помощью кеша будет, если проверяется каждая атомарная сущность на изменение, а не страница (часть страницы, например, где находятся сами коменты)?

Здесь же на 100 обращениях к базе теряется весь смысл кеша.

@maxic 6 янв 2009 в 11:54

Наконец-то, разработчики правильно начали подходить к своим проектам.
Т.е. сначала архитектура.
Вы совершенно правильно начали разработку и самое главное правильно определили путь проекта.
Т.е. самое главное объект. Тогда можно очень гибко подходить к развитию любого проекта — это очень радует.
Но прочтя комментарии, я как бы немного впал в ступор. Знаете почему. Мне совсем не понятно зачем делать 100 запросов на 100 комментов. Мне кажется вы немного ошиблись в проектировании архитектуры именно БД.
Можно вполне спокойно сделать это 1 запросом. Во всяком случае я так реализовал у себя. (это довольно легко кстати делается если вы в первую очередь сделали объектную ориентацию архитектуры)
Во вторых тогда можно сделать один гибкий, настраиваемый контроллер.
Если интересно пишите в личную.

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