Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
под кат пожалуйста
Анонс и исторя
А в заголовке-то буковку «и» забыли :)
>Например, у нас 100 комментариев к статье (100 запросов + 1 некешируемый на выборку списка id)
Жесть… 1 запросом никак не получиться?
Жесть… 1 запросом никак не получиться?
В кеше лежат отдельные объекты, а при выборке одним sql-запросом мы не знаем какие объекты закешированы, а какие нет — теряется смысл кеша.
>а при включенном — минимум 1
>При изменении одного комментария модератором — минимум 2
Дык всё равно будут запросы к базе будут, я бы не парился и выбирал бы 1!
>При изменении одного комментария модератором — минимум 2
Дык всё равно будут запросы к базе будут, я бы не парился и выбирал бы 1!
ничего не понял… отличие от старой версии только во внутренностях?
> Архитектура движка не позволяет выбирать несколько объектов одним запросом к БД — для каждого объекта свой запрос.
Мне кажется, что это ужасно. Когда у меня был приступ «давайте сделаем универсальный контент-репозитарий», этого удалось избежать с помощью небольшой денормализации (если память не изменяет).
Мне кажется, что это ужасно. Когда у меня был приступ «давайте сделаем универсальный контент-репозитарий», этого удалось избежать с помощью небольшой денормализации (если память не изменяет).
Я бы с большим интересом послушал об этом :)
хмм. позырил код в транке и то, что там есть сейчас — не для простых людей. не смог я полностью разобраться во всех таблицах этого «объектного» хранилища. но название класса «Object» очень понравилось :)
когда будет документация, мне кажется, можно будет что-то посоветовать в плане кеширования на уровне БД.
кстати, хорошая модель контент-репозитария у системы ez publish ( ez.no/doc/ez_publish/technical_manual/4_0/concepts_and_basics/content_management/datatypes ) у меня однажды был такой классный велик для хранения контента, а она мне все колеса отшибла ;-)
когда будет документация, мне кажется, можно будет что-то посоветовать в плане кеширования на уровне БД.
кстати, хорошая модель контент-репозитария у системы ez publish ( ez.no/doc/ez_publish/technical_manual/4_0/concepts_and_basics/content_management/datatypes ) у меня однажды был такой классный велик для хранения контента, а она мне все колеса отшибла ;-)
Вы молодец! Хватило хотя бы даже и того, что вы проект не бросили до сих пор, чтобы порадоваться.
Думаю дальше ужаснешься от текущий архитектуры и начнешь использовать фреймворки. Узнаешь про паттерны. А дальше может и python или ruby начнешь смотреть. Это нормально, главное не зацикливайся на каждом уровне больше 4-6 месяцев.
P.S. А много абстракций ни к чему хорошему не приводят. По крайне-мере на производительности это отражается в худшую сторону.
P.S. А много абстракций ни к чему хорошему не приводят. По крайне-мере на производительности это отражается в худшую сторону.
Не сочтите за завышенную самооценку, но про паттерны и фреймфорки я знаю, а паттерны еще и умудряюсь применять. Про Python & Ruby спорить не буду, но мне пока PHP & C++ хватает :)
По поводу абстракций да, но если есть возможности, почему бы их не использовать? Мое мнение: лучше потратиться один раз на мощный сервер, а не платить постоянно огромные деньги за разработку.
Вообще конечно похвальное увлечение, но по сути получается велосипед, причем далеко не лучший.
ИМХО, фреймворки не дураки придумали.
ИМХО, фреймворки не дураки придумали.
Прочитав статейку, подумал что вы написали не CMS, а фреймворко-CMS
Спасибо вам за старания, надеюсь, новая, 3 версия будет много лучше предыдущей. Удачи вам!
Ну что ж, будем следить за развитием! Текущие ветки совсем забросил? Err 500 частенько падает на текущих сайтах…
:-) Двигайся дальше.
> CMS ориентирована на создание социальных сетей и интернет-сообществ, то кеширование — это все
Несколько вопросов.
1. Есть какие-то замеры? Например типичная простая страничка 10 объектов (начала статей), листалка, навигация. Или же статейка с комментариями. На каком железе сколько запросов обрабатывается без кэша и сколько с кэшем в секунду. Например устроив стресс тест с помощью http_load.
2. Как определяется что попадает в кэш а что нет? Заносить все — памяти у серверов много, но в пределах разумного =) А если не все объекты в памяти не держать, то с базой желательно работать более-менее оптимально
> лучше потратиться один раз на мощный сервер
все понятие относительное. говорить о удачности или неудачности того или иного решения можно когда есть числа, а не обсуждая сферического коня в вакууме. Например, сталкивался с системой, написаной очень модно, но обрабатывающей два запроса в секунду на четырехядерном сервере, что на мой взгляд ни в какие ворота.
Несколько вопросов.
1. Есть какие-то замеры? Например типичная простая страничка 10 объектов (начала статей), листалка, навигация. Или же статейка с комментариями. На каком железе сколько запросов обрабатывается без кэша и сколько с кэшем в секунду. Например устроив стресс тест с помощью http_load.
2. Как определяется что попадает в кэш а что нет? Заносить все — памяти у серверов много, но в пределах разумного =) А если не все объекты в памяти не держать, то с базой желательно работать более-менее оптимально
> лучше потратиться один раз на мощный сервер
все понятие относительное. говорить о удачности или неудачности того или иного решения можно когда есть числа, а не обсуждая сферического коня в вакууме. Например, сталкивался с системой, написаной очень модно, но обрабатывающей два запроса в секунду на четырехядерном сервере, что на мой взгляд ни в какие ворота.
> Синтаксис: {{имя_модуля:: название_метода(параметры)}}.
>… но он явно быстрее подгрузки XML-таблиц прямо в XSLT через document()
А это действительно на существенно быстрее?
PS Кстати, Explay3 на UMI.CMS чем-то похожа (как мне показалось)
>… но он явно быстрее подгрузки XML-таблиц прямо в XSLT через document()
А это действительно на существенно быстрее?
PS Кстати, Explay3 на UMI.CMS чем-то похожа (как мне показалось)
PS Кстати, Explay3 на UMI.CMS чем-то похожа (как мне показалось)
Может, потому что lauri работает(или работал) над umi?)
Быстрее: в тойже ЮМИ в XSLT шаблонах везде обращение к сайту через document(), при этом куча времени уходит на генерацию запрашиваемой страницы, а в случае Explay время отработки макроса — это только лишь время работы вызываемого модуля.
Напоминает Drupal, лет этак 5 назад, да? :)
lauri Все без исключения методы уже комментированы для дальнейшего составления документации.
doxygen в помощь и ничего не надо писать ручками, если комментированы по правилам.
doxygen в помощь и ничего не надо писать ручками, если комментированы по правилам.
Начнем с того, что фирменного стиля Вы еще не видели и не надо строить предаоложения, что это будет синий, немного эпполовский, дизайн. Во-вторых, я уважаю труд разработчиков Юмисофта и я бы не стал пи… их труд, хотя бы по этой причине. Никто в веб-разработке за последниие 3-5 лет не изобретал ничего революционно нового =) Подумайте, прежде, чем обвинять кого-либо в пи…
Для меня интерес представляла ваша структура БД, просто для ознакомления, так как, судя по описанию, я предположил, что она достойна того, чтобы на нее взглянуть. Просматривая sql-файл, вспомнилась проблема, с которой я недавно столкнулся при проектировании. Похожая проблема на stackoverflow. Архитектура БД, конечно, разная, но суть в негативном отношении профессионалов к применению метода Entity-attribute-value.
Насчет кеша.
Один запрос будет быстрее, чем 100 обращений к memcached, тем более к диску.
Мне нравится такая схема: в самой таблице с объектами (как вариант в присоединенной, всеже шаблонов на тип может быть несколько) хранится кеш. Выборка айдишников идет вместе с кешем, смотрится если кеш есть — выводится он. Если кеш пуст — вызывается что-то, что кеш заполнит, внесет его в таблицу объектов и отдаст выводу. Лучше сразу после получения кешей определять объекты с промохом, делать на всех один запрос и заполнять кеш тоже одним запросом.
В результате при пустом кеше: 1 запрос легкий, кеш пустой, одни айдишники. 1 запрос тяжелый, скопом собираем всю информацию для всех объектов, которые нужно вывести. Один мощный апдейт.
При полном кеше: один запрос достаточно тяжелый по трафику, но зато в нем уже прямой вывод на страницу.
Один запрос будет быстрее, чем 100 обращений к memcached, тем более к диску.
Мне нравится такая схема: в самой таблице с объектами (как вариант в присоединенной, всеже шаблонов на тип может быть несколько) хранится кеш. Выборка айдишников идет вместе с кешем, смотрится если кеш есть — выводится он. Если кеш пуст — вызывается что-то, что кеш заполнит, внесет его в таблицу объектов и отдаст выводу. Лучше сразу после получения кешей определять объекты с промохом, делать на всех один запрос и заполнять кеш тоже одним запросом.
В результате при пустом кеше: 1 запрос легкий, кеш пустой, одни айдишники. 1 запрос тяжелый, скопом собираем всю информацию для всех объектов, которые нужно вывести. Один мощный апдейт.
При полном кеше: один запрос достаточно тяжелый по трафику, но зато в нем уже прямой вывод на страницу.
Здорово :) С любопытством слежу за развитием LiveStreet и Explay. После этой публикации ставлю мысленный "+" Explay. Предыдущий код был ужасен поистине… А этот намного-много лучше!
Конечно, запрет «нескольких объектов одним запросом» в пользу кеширования — это смелый ход. Подумаю на досуге насколько он может быть оправдан. На самом деле я сам давно заметил тенденцию упрощения запросов в наших проектах с JOIN-ов на пост-JOIN-ы. Только по 100 элементов мы обычно не выбираем, а используем несколько WHERE id IN ()
Конечно, запрет «нескольких объектов одним запросом» в пользу кеширования — это смелый ход. Подумаю на досуге насколько он может быть оправдан. На самом деле я сам давно заметил тенденцию упрощения запросов в наших проектах с JOIN-ов на пост-JOIN-ы. Только по 100 элементов мы обычно не выбираем, а используем несколько WHERE id IN ()
хм… блин, что-то интерестное… точнее странное… нельзя выбрать например одним запрос много комментов? насколько это оправдано? если так получиться, что кэш уйдет в даун, а на сайте будет около 5000 тем, в каждом по 500 комментариев… это ж скока нужно времени будет первому «счастливчику», который зайдет на сайт… он походу успеет вырастить ребенка и построить дом и посадить дерево… за это время пока ему откроется главная… вообще код клевый, но выборка из базы- что-то нужно с этим делать… неужели нету других вариантов?
P/S а функцией Count можно пользоваться? или подсчитывать нужно по одному объекту?
P/S а функцией Count можно пользоваться? или подсчитывать нужно по одному объекту?
explay/classes/i18n.parser.php
/**
* Купить:
* — молоко «Простоквашино»
* — бананы
* — шампунь
* — мыло (жидкое + обычное)
* —!!! масло «Русские кружева»!!!
*/
/**
* Купить:
* — молоко «Простоквашино»
* — бананы
* — шампунь
* — мыло (жидкое + обычное)
* —!!! масло «Русские кружева»!!!
*/
Нашёл у вас дырку: example.com/my/__default();var_export($this);die
Давайте незачётку! eval без должной фильтрации запроса до добра не доведёт =)
А ещё: подскажите, пожалуйста, где у вас там находится место, в котором происходят выборки объектов (из кэша, а если нет — из таблиц)
Давайте незачётку! eval без должной фильтрации запроса до добра не доведёт =)
А ещё: подскажите, пожалуйста, где у вас там находится место, в котором происходят выборки объектов (из кэша, а если нет — из таблиц)
Как раз в раздумьях про фильтрацию eval'ов, у Вас случайно нет идеи?
Объекты проходят через ObjectsController, в частности ObjectsController::getObject (...);
Объекты проходят через ObjectsController, в частности ObjectsController::getObject (...);
Имхо, в каждом отдельном случае должны быть свои проверки.
Ещё можно посмотреть в сторону Reflection
if (!method_exists($this->modules[$moduleName]['object'], $method))
throw new CoreException (lang('error_controller_module_return_invalid_object','core'));
Ещё можно посмотреть в сторону Reflection
ObjectsController::getObject (...);Я тут покопался в коде, почитал комменты…
В кеше лежат отдельные объекты, а при выборке одним sql-запросом мы не знаем какие объекты закешированы, а какие нет — теряется смысл кеша.Именно поэтому вы и не сможете уйти от ста (или тысяч ?) запросов к кэшу/БД.
Имхо:
Вы не то кэшируете. Запись таблицы — слишком маленькая сущность, чтобы быть закэшированной.
Если вы от этого не откажетесь, именно в «социальных сетях и интернет-сообществах» ваши принципы кэширования проявят себя с отрицательной строны. Правда, если откажетесь — придётся всё переделывать.
Имхо, вы не правы. Отдельный объект — это отличная сущность для кеширования, особенно в «социальных сетях и интернет-сообществах», где можно вывести объекты сначала по хранологии, потом по тегам, потом по авторам и по вашей схеме 10 раз пересторить кеш.
Может быть и не прав.
Что лучше Объект «100 Комментариев» или 100 Объектов «Комментарий»?
Отдельный объект — это отличная сущность для кешированияНо с другой стороны — всё зависит от того, что именно считать за объект!
Что лучше Объект «100 Комментариев» или 100 Объектов «Комментарий»?
Если комментарии древодины — очевидно, что рациональнее второй вариант. Если линейны — первый, причем можно даже кеш не перестраивать, а дозаписывать новыми комментариями.
В этом случае надо учитывать одну особенность комментариев: отношение между прочитанными комментариями и добавленными. Пускай будет 100:1 (100 раз прочитали, один добавили). Очевидно, что менее накладно будет перезаписать структуру с комментариями, чем каждый раз искать закеширован ли каждый коммент.
И потом, возникает вопрос: в чём тогда ускорение с помощью кеша будет, если проверяется каждая атомарная сущность на изменение, а не страница (часть страницы, например, где находятся сами коменты)?
Здесь же на 100 обращениях к базе теряется весь смысл кеша.
И потом, возникает вопрос: в чём тогда ускорение с помощью кеша будет, если проверяется каждая атомарная сущность на изменение, а не страница (часть страницы, например, где находятся сами коменты)?
Здесь же на 100 обращениях к базе теряется весь смысл кеша.
Наконец-то, разработчики правильно начали подходить к своим проектам.
Т.е. сначала архитектура.
Вы совершенно правильно начали разработку и самое главное правильно определили путь проекта.
Т.е. самое главное объект. Тогда можно очень гибко подходить к развитию любого проекта — это очень радует.
Но прочтя комментарии, я как бы немного впал в ступор. Знаете почему. Мне совсем не понятно зачем делать 100 запросов на 100 комментов. Мне кажется вы немного ошиблись в проектировании архитектуры именно БД.
Можно вполне спокойно сделать это 1 запросом. Во всяком случае я так реализовал у себя. (это довольно легко кстати делается если вы в первую очередь сделали объектную ориентацию архитектуры)
Во вторых тогда можно сделать один гибкий, настраиваемый контроллер.
Если интересно пишите в личную.
Т.е. сначала архитектура.
Вы совершенно правильно начали разработку и самое главное правильно определили путь проекта.
Т.е. самое главное объект. Тогда можно очень гибко подходить к развитию любого проекта — это очень радует.
Но прочтя комментарии, я как бы немного впал в ступор. Знаете почему. Мне совсем не понятно зачем делать 100 запросов на 100 комментов. Мне кажется вы немного ошиблись в проектировании архитектуры именно БД.
Можно вполне спокойно сделать это 1 запросом. Во всяком случае я так реализовал у себя. (это довольно легко кстати делается если вы в первую очередь сделали объектную ориентацию архитектуры)
Во вторых тогда можно сделать один гибкий, настраиваемый контроллер.
Если интересно пишите в личную.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анонс и история Explay CMS 3 (Core)