Как стать автором
Обновить

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

под кат пожалуйста
спасибо, исправился :)
Из под ката, пожалуйста.
Анонс и исторя

А в заголовке-то буковку «и» забыли :)
спасибо, представляю что в коде :)
>Например, у нас 100 комментариев к статье (100 запросов + 1 некешируемый на выборку списка id)
Жесть… 1 запросом никак не получиться?
В кеше лежат отдельные объекты, а при выборке одним sql-запросом мы не знаем какие объекты закешированы, а какие нет — теряется смысл кеша.
>а при включенном — минимум 1
>При изменении одного комментария модератором — минимум 2

Дык всё равно будут запросы к базе будут, я бы не парился и выбирал бы 1!
НЛО прилетело и опубликовало эту надпись здесь
Ой не факт…
Подобная стратегия работает хорошо если у вас памяти под кэш немеряно, да и то… очень уж разные ситуации бывают и жёстко оставлять только один вариант — могут быть большие проблемы.
Памяти под кеш всегда «немеряно» — память очень дешевая, мемкеш очень легко масштабируется. Обычно в это не упирается. А вот в количество запросов (по 1 на каждый комментарий) — как раз можно и упереться.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Считаю это правильнее, нежели писать шаблонизатор на шаблонизаторе. Тем более возможно прикрутить тот же Smarty.
странно, если вы к пхп относитесь как к шаблонизатору, почемы вы до сих пор, пишите на нем подобные проекты. =)
ничего не понял… отличие от старой версии только во внутренностях?
старая еще и работала, а эта пока не совсем :)
да, я тоже мучаюсь — никак не могу заставить работать уже битый час =)
это отнюдь не ужасно :)
> Архитектура движка не позволяет выбирать несколько объектов одним запросом к БД — для каждого объекта свой запрос.

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

кстати, хорошая модель контент-репозитария у системы ez publish ( ez.no/doc/ez_publish/technical_manual/4_0/concepts_and_basics/content_management/datatypes ) у меня однажды был такой классный велик для хранения контента, а она мне все колеса отшибла ;-)
Вы молодец! Хватило хотя бы даже и того, что вы проект не бросили до сих пор, чтобы порадоваться.
НЛО прилетело и опубликовало эту надпись здесь
Обязательные:

mb_string

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

P.S. А много абстракций ни к чему хорошему не приводят. По крайне-мере на производительности это отражается в худшую сторону.
Не сочтите за завышенную самооценку, но про паттерны и фреймфорки я знаю, а паттерны еще и умудряюсь применять. Про Python & Ruby спорить не буду, но мне пока PHP & C++ хватает :)
По поводу абстракций да, но если есть возможности, почему бы их не использовать? Мое мнение: лучше потратиться один раз на мощный сервер, а не платить постоянно огромные деньги за разработку.
До определенного предела это окупается. Но по мере роста нагрузки становится выгоднее оптимизировать код, чем покупать железо. Представьте себе масштабы Яндекс или vkontakte, например.
НЛО прилетело и опубликовало эту надпись здесь
Вам теперь надо XSLT к PHP подключить
[offtop]
> Fatal error: Class XSLTProcessor or him interface not found!
А почему «him»? Если я правильно понимаю, то «its» или хотя бы «his»?[/offtop]
Вообще конечно похвальное увлечение, но по сути получается велосипед, причем далеко не лучший.
ИМХО, фреймворки не дураки придумали.
Велосипед — да, зато есть чем гордится и к чему стремиться :)
Прочитав статейку, подумал что вы написали не CMS, а фреймворко-CMS
На данный момент так и есть. CMS с админкой будет дальше.
Спасибо вам за старания, надеюсь, новая, 3 версия будет много лучше предыдущей. Удачи вам!
Ну что ж, будем следить за развитием! Текущие ветки совсем забросил? Err 500 частенько падает на текущих сайтах…
Да, и в админку сервера доступа нет =\
Это к Александру :)
:-) Двигайся дальше.
> CMS ориентирована на создание социальных сетей и интернет-сообществ, то кеширование — это все
Несколько вопросов.
1. Есть какие-то замеры? Например типичная простая страничка 10 объектов (начала статей), листалка, навигация. Или же статейка с комментариями. На каком железе сколько запросов обрабатывается без кэша и сколько с кэшем в секунду. Например устроив стресс тест с помощью http_load.
2. Как определяется что попадает в кэш а что нет? Заносить все — памяти у серверов много, но в пределах разумного =) А если не все объекты в памяти не держать, то с базой желательно работать более-менее оптимально
> лучше потратиться один раз на мощный сервер
все понятие относительное. говорить о удачности или неудачности того или иного решения можно когда есть числа, а не обсуждая сферического коня в вакууме. Например, сталкивался с системой, написаной очень модно, но обрабатывающей два запроса в секунду на четырехядерном сервере, что на мой взгляд ни в какие ворота.
> Синтаксис: {{имя_модуля:: название_метода(параметры)}}.
>… но он явно быстрее подгрузки XML-таблиц прямо в XSLT через document()

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

PS Кстати, Explay3 на UMI.CMS чем-то похожа (как мне показалось)
Ваша правда :)
поправочка — все-таки работал
Вот ведь, а =)
А я думал, что заговор раскрыл. Отбой =)
Быстрее: в тойже ЮМИ в XSLT шаблонах везде обращение к сайту через document(), при этом куча времени уходит на генерацию запрашиваемой страницы, а в случае Explay время отработки макроса — это только лишь время работы вызываемого модуля.
Жаль. Мне идея с document() очень понравилась… Надо будет замеры какие-нибудь сделать.
Document(), как родной способ, будет, конечно, красивее, а макросы в XSLT — это, к сожалению, костыль. Возможности движка позволяют использовать оба способа, достаточно вызвать необходимую страницу с расширением xml.
НЛО прилетело и опубликовало эту надпись здесь
Напоминает Drupal, лет этак 5 назад, да? :)
Я с друпалом дела не имел. Он 5 лет назад был на ООП?
Думаю был, он довольно взрослый :) Просто ООП в нём реализовано на непривычном для большинства уровне, классов совсем нет.
он и сейчас не ооп ))
Для вас ООП — это классы?
lauri Все без исключения методы уже комментированы для дальнейшего составления документации.

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

НЛО прилетело и опубликовало эту надпись здесь
А где у Юмисофта 3-ка? 0_о
НЛО прилетело и опубликовало эту надпись здесь
Начнем с того, что фирменного стиля Вы еще не видели и не надо строить предаоложения, что это будет синий, немного эпполовский, дизайн. Во-вторых, я уважаю труд разработчиков Юмисофта и я бы не стал пи… их труд, хотя бы по этой причине. Никто в веб-разработке за последниие 3-5 лет не изобретал ничего революционно нового =) Подумайте, прежде, чем обвинять кого-либо в пи…
Для меня интерес представляла ваша структура БД, просто для ознакомления, так как, судя по описанию, я предположил, что она достойна того, чтобы на нее взглянуть. Просматривая sql-файл, вспомнилась проблема, с которой я недавно столкнулся при проектировании. Похожая проблема на stackoverflow. Архитектура БД, конечно, разная, но суть в негативном отношении профессионалов к применению метода Entity-attribute-value.
Насчет кеша.
Один запрос будет быстрее, чем 100 обращений к memcached, тем более к диску.
Мне нравится такая схема: в самой таблице с объектами (как вариант в присоединенной, всеже шаблонов на тип может быть несколько) хранится кеш. Выборка айдишников идет вместе с кешем, смотрится если кеш есть — выводится он. Если кеш пуст — вызывается что-то, что кеш заполнит, внесет его в таблицу объектов и отдаст выводу. Лучше сразу после получения кешей определять объекты с промохом, делать на всех один запрос и заполнять кеш тоже одним запросом.

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

Конечно, запрет «нескольких объектов одним запросом» в пользу кеширования — это смелый ход. Подумаю на досуге насколько он может быть оправдан. На самом деле я сам давно заметил тенденцию упрощения запросов в наших проектах с JOIN-ов на пост-JOIN-ы. Только по 100 элементов мы обычно не выбираем, а используем несколько WHERE id IN ()
хм… блин, что-то интерестное… точнее странное… нельзя выбрать например одним запрос много комментов? насколько это оправдано? если так получиться, что кэш уйдет в даун, а на сайте будет около 5000 тем, в каждом по 500 комментариев… это ж скока нужно времени будет первому «счастливчику», который зайдет на сайт… он походу успеет вырастить ребенка и построить дом и посадить дерево… за это время пока ему откроется главная… вообще код клевый, но выборка из базы- что-то нужно с этим делать… неужели нету других вариантов?
P/S а функцией Count можно пользоваться? или подсчитывать нужно по одному объекту?
НЛО прилетело и опубликовало эту надпись здесь
explay/classes/i18n.parser.php

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

А ещё: подскажите, пожалуйста, где у вас там находится место, в котором происходят выборки объектов (из кэша, а если нет — из таблиц)
Как раз в раздумьях про фильтрацию eval'ов, у Вас случайно нет идеи?

Объекты проходят через ObjectsController, в частности ObjectsController::getObject (...);
Имхо, в каждом отдельном случае должны быть свои проверки.
if (!method_exists($this->modules[$moduleName]['object'], $method))
 throw new CoreException (lang('error_controller_module_return_invalid_object','core'));

Ещё можно посмотреть в сторону Reflection
Спасибо, исправил :) Правда method_exists () тут не обошлось — в модулях можно реализовывать множественное наследование, поэтому пришлось писать свой method_exists ().
ObjectsController::getObject (...);
Я тут покопался в коде, почитал комменты…
В кеше лежат отдельные объекты, а при выборке одним sql-запросом мы не знаем какие объекты закешированы, а какие нет — теряется смысл кеша.
Именно поэтому вы и не сможете уйти от ста (или тысяч ?) запросов к кэшу/БД.

Имхо:
Вы не то кэшируете. Запись таблицы — слишком маленькая сущность, чтобы быть закэшированной.
Если вы от этого не откажетесь, именно в «социальных сетях и интернет-сообществах» ваши принципы кэширования проявят себя с отрицательной строны. Правда, если откажетесь — придётся всё переделывать.
Имхо, вы не правы. Отдельный объект — это отличная сущность для кеширования, особенно в «социальных сетях и интернет-сообществах», где можно вывести объекты сначала по хранологии, потом по тегам, потом по авторам и по вашей схеме 10 раз пересторить кеш.
Может быть и не прав.
Отдельный объект — это отличная сущность для кеширования
Но с другой стороны — всё зависит от того, что именно считать за объект!
Что лучше Объект «100 Комментариев» или 100 Объектов «Комментарий»?
Если комментарии древодины — очевидно, что рациональнее второй вариант. Если линейны — первый, причем можно даже кеш не перестраивать, а дозаписывать новыми комментариями.
В этом случае надо учитывать одну особенность комментариев: отношение между прочитанными комментариями и добавленными. Пускай будет 100:1 (100 раз прочитали, один добавили). Очевидно, что менее накладно будет перезаписать структуру с комментариями, чем каждый раз искать закеширован ли каждый коммент.
И потом, возникает вопрос: в чём тогда ускорение с помощью кеша будет, если проверяется каждая атомарная сущность на изменение, а не страница (часть страницы, например, где находятся сами коменты)?

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