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