1. Насколько сложные сообщения можно создавать для SObjectizer'a. То есть интересует вопрос впихивания, например, списков да и вообще контейнеров из STL.
2. И главный вопрос — есть ли возможность прикрутить свой собственный сериализатор/десериализатор. Или появится ли такая возможность в будущем?
И это правильно
M>1. Насколько сложные сообщения можно создавать для SObjectizer'a. То есть интересует вопрос впихивания, например, списков да и вообще контейнеров из STL.
Если сообщение не будет выходить за пределы процесса, то на структуру сообщения вообще практически никаких ограничений нет. Хоть STL-контейнеры, хоть Boost-, хоть Qt- и т.д.
Если же сообщение принадлежит глобальному агенту и должно ходить по SOP, то допускаются поля примитивных типов (char, short, int, float, double, std::string) и сериализуемых средствами ObjESSty
типов (а там поддерживаются многие STL контейнеры, указатели). Так же ObjESSty позволяет прикручивать собственную сериализацию для произвольных типов (например, так в ObjESSty сделана сериализация типа ACE_Date_Time).
M>2. И главный вопрос — есть ли возможность прикрутить свой собственный сериализатор/десериализатор. Или появится ли такая возможность в будущем?
В принципе, можно. Хотя в SObjectizer-е пока не заложено возможности использования сторонних сериализаторов для SOP. Что касается появления такой возможности в будущем, то все зависит от спроса
Если будет очень нужно, то можно будет и сделать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
M>>2. И главный вопрос — есть ли возможность прикрутить свой собственный сериализатор/десериализатор. Или появится ли такая возможность в будущем?
E>В принципе, можно. Хотя в SObjectizer-е пока не заложено возможности использования сторонних сериализаторов для SOP. Что касается появления такой возможности в будущем, то все зависит от спроса E>Если будет очень нужно, то можно будет и сделать.
Нужно-нужно
Вернее, было бы неплохо Я сейчас, правда, с ходу не придумаю, но, например, для "моментальной" интеграции с уже существующими системами.
Здравствуйте, Mamut, Вы писали:
E>>Если будет очень нужно, то можно будет и сделать.
M>Нужно-нужно
M>Вернее, было бы неплохо Я сейчас, правда, с ходу не придумаю, но, например, для "моментальной" интеграции с уже существующими системами.
А какие именно системы сериализации интересуют в первую очередь?
И идет ли речь об интероперабельности только с C++ или другими языками? (Просто у меня есть желание сделать поддержку ObjESSty в Ruby, а затем и порт SObjectizer на Ruby. В этом случае другие системы сериализации не смогут с SObjectizerOnRuby взаимодействовать).
Дмитрий, извини за офтопик, но хотел спросить про @linux. А вариант реализации @linux на Erlang рассматривался (ты же им интересовался, вроде)? Имхо, нарисованная Sheridan структура вполне бы легла на Erlang. Да и такая идея могла бы найти своих сторонников из числа участников "Декларативного программирования"
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>А какие именно системы сериализации интересуют в первую очередь? E>И идет ли речь об интероперабельности только с C++ или другими языками? (Просто у меня есть желание сделать поддержку ObjESSty в Ruby, а затем и порт SObjectizer на Ruby. В этом случае другие системы сериализации не смогут с SObjectizerOnRuby взаимодействовать).
То есть если бы была возможность сделать типа registerSerializer(mySerializer), где mySerializer — класс, принимающий на входе некий so_message, а на выходе — свой формат (JSON, XML, DCOP, SOAP, свой протокол), было бы здорово.
Ну и это бы позволило общение и сдругими языками тоже (через тот же JSON, например)
E> E>Дмитрий, извини за офтопик, но хотел спросить про @linux. А вариант реализации @linux на Erlang рассматривался (ты же им интересовался, вроде)? Имхо, нарисованная Sheridan структура вполне бы легла на Erlang. Да и такая идея могла бы найти своих сторонников из числа участников "Декларативного программирования"
У меня уже месяца четыре как мечта идиота — серверную часть на Эрланге реализовать Но времени даже обучится Эрлангу нет (пока что слегка поковырял Мнезию и xmerl).
Здравствуйте, Mamut, Вы писали:
E>>А какие именно системы сериализации интересуют в первую очередь? E>>И идет ли речь об интероперабельности только с C++ или другими языками? (Просто у меня есть желание сделать поддержку ObjESSty в Ruby, а затем и порт SObjectizer на Ruby. В этом случае другие системы сериализации не смогут с SObjectizerOnRuby взаимодействовать).
M>Наверное, JSON (особенно в свете Comments.Planning-Protocol (в самом низу)). Я также понимаю, что и какой-нить ASN.1 тоже not out of the question. И вообще, мало ли народ собственных протоколов придумывает
В копилочку: есть еще такая отличная штука как YAML — как JSON, только круче
M>>Наверное, JSON (особенно в свете Comments.Planning-Protocol (в самом низу)). Я также понимаю, что и какой-нить ASN.1 тоже not out of the question. И вообще, мало ли народ собственных протоколов придумывает
ЗХ>В копилочку: есть еще такая отличная штука как YAML — как JSON, только круче
Здравствуйте, Mamut, Вы писали:
E>>А какие именно системы сериализации интересуют в первую очередь?
M>Наверное, JSON (особенно в свете Comments.Planning-Protocol (в самом низу)). Я также понимаю, что и какой-нить ASN.1 тоже not out of the question. И вообще, мало ли народ собственных протоколов придумывает
Вообще-то ты перечислил форматы, а я спрашивал про библиотеки/фреймворки, которые могут эти или другие форматы поддерживать. Вроде Boost.Serialization или s11n.net. Все-таки, к хорошему быстро привыкаешь и, когда в программе есть возможность манипулировать просто прикладными объектами, то о лежащем в низу протоколе уже не думаешь. Например, представь себе, что система сериализации позволяет тебе работать такими объектами:
class Message_Info {
public :
Message_Id get_id() const;
User_Id author() const;
Date_Time sent_at() const;
...
};
class Forum_Topic_Info {
public :
Forum_Id get_id() const;
std::string subject() const;
Date_Time created_at() const;
...
};
class Forum_Topic_Updates {
public :
std::list< Message_Info >
updates() const;
...
};
class Last_Changes {
public :
std::map< Forum_Topic_Info, Forum_Topic_Updates >
changes() const;
...
};
то уже без особой разницы, в какой поток байт объекты этих типов преобразуются. Важно то, если ли возможность в программе просто передавать эти объекты куда-либо, или же нужно куда-то что-то преобразовывать. Системы сериализации вроде ObjESSty, Boost.Serialization, s11n как раз снимает с разработчика необходимость думать о тонкостях результирующего формата.
<offtopic>
В обсуждении по данной тобой ссылке мне больше всего понравилась фраза:
Опять же настоятельно требую посмотреть на ICE или другие, уже готовые реализации протоколов
+1
Очень правильные слова.
</offtopic>
M>То есть если бы была возможность сделать типа registerSerializer(mySerializer), где mySerializer — класс, принимающий на входе некий so_message, а на выходе — свой формат (JSON, XML, DCOP, SOAP, свой протокол), было бы здорово.
Тут напрашивается аналогия с Multi Agent System (http://www.fipa.org). Там выделяются понятия Message, Encoding-Service, Transport-Message, Transport. Message-Transport-Service. Что позволяет одно и то же сообщение (объект Message) преобразовать с помощью разных форматов (через Encoding-Service) в разные транспортные объекты (Transport-Message), которые передаются через различные Message-Transpore-Service.
В SObjectizer до сих пор была очень легковесная (хотя и жесткая) схема -- один тип формата, один протокол, один тип транспорта (TCP, хотя можно приспособить и другие stream-oriented транспорты, вроде pipes). Для того, чтобы внедрить поддержку разных форматов в SObjectizer придется вводить подобное разделение обязанностей. В результате тот же FIPA и получится, только доморощенный
Естественно, если в этом будет необходимость, можно будет докрутить SObjectizer и до такой крутизны
M>Ну и это бы позволило общение и сдругими языками тоже (через тот же JSON, например)
С другими языками проблема не только в том, чтобы уметь объект-сообщение десериализовать. Нужно еще уметь соединения с SObjectizer приложениями устанавливать, процедуру handshake проходить, соединения в работоспособности проверять, обмениваться данными. В таких условиях, имхо, проще для конкретного языка сделать порт части SObjectizer (хотя бы поддержки транспорта и SOP) и ObjESSty (сериализацию). А тогда уже особого смысла в других форматах может и не быть
M>Дур... Умные люди действительно мыслят одинаково
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>>>А какие именно системы сериализации интересуют в первую очередь?
M>>Наверное, JSON (особенно в свете Comments.Planning-Protocol (в самом низу)). Я также понимаю, что и какой-нить ASN.1 тоже not out of the question. И вообще, мало ли народ собственных протоколов придумывает
E>Вообще-то ты перечислил форматы, а я спрашивал про библиотеки/фреймворки, которые могут эти или другие форматы поддерживать. Вроде Boost.Serialization или s11n.net.
Ааа... Хмм... Так я навскидку и не придумаю... В голову лезет всякая фигня типа веб-сервисов и ЯваСкрипта. Или какой-нибудь Jabber (XMPP) или даже Libjingle. Из того, что действительно могло бы понадобиться — разве что действительно общение с программами, написаными на других языках (хотя бы с тем же эрлангом, например ).
E>Все-таки, к хорошему быстро привыкаешь и, когда в программе есть возможность манипулировать просто прикладными объектами, то о лежащем в низу протоколе уже не думаешь. Например, представь себе, что система сериализации позволяет тебе работать такими объектами: E>
E>
E>то уже без особой разницы, в какой поток байт объекты этих типов преобразуются. Важно то, если ли возможность в программе просто передавать эти объекты куда-либо, или же нужно куда-то что-то преобразовывать. Системы сериализации вроде ObjESSty, Boost.Serialization, s11n как раз снимает с разработчика необходимость думать о тонкостях результирующего формата.
Вот это оно самое и нужно Если бы еще не забивать гоглову о том, а как это та, другая сторона, принимать будет...
M>>То есть если бы была возможность сделать типа registerSerializer(mySerializer), где mySerializer — класс, принимающий на входе некий so_message, а на выходе — свой формат (JSON, XML, DCOP, SOAP, свой протокол), было бы здорово.
E>Тут напрашивается аналогия с Multi Agent System (http://www.fipa.org). Там выделяются понятия Message, Encoding-Service, Transport-Message, Transport. Message-Transport-Service. Что позволяет одно и то же сообщение (объект Message) преобразовать с помощью разных форматов (через Encoding-Service) в разные транспортные объекты (Transport-Message), которые передаются через различные Message-Transpore-Service.
E>В SObjectizer до сих пор была очень легковесная (хотя и жесткая) схема -- один тип формата, один протокол, один тип транспорта (TCP, хотя можно приспособить и другие stream-oriented транспорты, вроде pipes). Для того, чтобы внедрить поддержку разных форматов в SObjectizer придется вводить подобное разделение обязанностей. В результате тот же FIPA и получится, только доморощенный
Зато готовый, который пощупать руками можно. А то от ФИПЫ ничего, кроме спецификаций, не дождешься
E>Естественно, если в этом будет необходимость, можно будет докрутить SObjectizer и до такой крутизны
Ага, ага
M>>Ну и это бы позволило общение и сдругими языками тоже (через тот же JSON, например)
E>С другими языками проблема не только в том, чтобы уметь объект-сообщение десериализовать. Нужно еще уметь соединения с SObjectizer приложениями устанавливать, процедуру handshake проходить, соединения в работоспособности проверять, обмениваться данными. В таких условиях, имхо, проще для конкретного языка сделать порт части SObjectizer (хотя бы поддержки транспорта и SOP) и ObjESSty (сериализацию). А тогда уже особого смысла в других форматах может и не быть
Предположим такой маньячный вариант: Клиент подсоединяется к некой программе, как к веб-серверу. Все, что у клиента есть, — это веб-интерфейс и ЯваСкрипт (он же Аякс). ЯваСкрипт, соответственно, работает через JSON, потому что так легче. На серваке все равно придется писать прослойку JSON <-> SObjectizer, потому что реализовать SOP и сериализацию, наверное, можно и на ЯваСкрипте, но лучше не надо
Сюда же можно отнести, наверное, любые приложения, используюшие что-либо из этого списка. Да и мало ли Вон, в @линух тоже свой протокол собираются писать Я, правда, не дамся
Когда речь заходит о прозрачной интероперабельности SObjectizer с приложениями на других языках, вопрос, имхо, упирается в то, будут ли приложения понимать (и принимать) агентно-ориентированную семантику, или нет.
Возьмем, к примеру создание SOP соединений. После создания физического канала стороны должны провести процедуру handshake и произвести обмен фильтрами. После этого в канале начнут циркулировать сообщения агентов. При этом сообщение идет не как RPC-like обмен запрос-ответ, а как поток PDU, в каждом из которых находится свое сообщение. Далее, в каждом сообщении кроме самих полей сообщения передается метаинформация, как то: имя агента-владельца, имя сообщения, имя получателя, задержка перед отправкой.
Все это я говорю к тому, что:
* некоторые типы протоколов (например, XML-PRC, SOAP) не ложатся просто так на текущую модель SOP. Поддержка таких протоколов прозрачным для SObjectizer-агентов образом потребует создания неких шлюзов, имитирующих наличие SOP-каналов, их фильтры, их живучесть и пр.;
* поскольку для SOP нужна метаинформация к каждому сообщению, не получится приспосабливать какой-то готовый прикладной протокол для взаимодействия с SObjectizer, поскольку в этом случае в элементах прикладного протокола не предусмотрена метаинформация для SObjectizer;
* сторона, обращающаяся к SObjectizer должна понимать, что взаимодействие асинхронное и на отсланное сообщение не будет мнгновенного ответа. Соответственно, придется вместо привычного RPC-line стиля взаимодействия запрос-ответ, использовать у себя что-то другое;
* если SObjectizer сможет поддерживать набор разных внешних протоколов и форматов (как то JSON, YAML, XML и др.), то тогда встанет вопрос о том, как одно и то же сообщение сериализовать в каждый из форматов. Т.е. придется двигаться в сторону FIPA с ее content-language, encoding-service и пр.
Самый главный момент в том, что нужно понимать, если в SObjectizer отсылается какое-то сообщение Last_Changes, то просто по семантике агентно-ориентированного взаимодействия оно не может придти в том же самом виде в какое-то Java-приложение. Если только это Java-приложение не ожидало вместо Last_Changes сообщение SobjAgentMessage, в котором Last_Changes было бы всего лишь полем messagePayload.
Поэтому мне кажется, что если необходимо обеспечить прозрачное взаимодействие SObjectizer с другими приложениями, то это нужно делать не на основе адаптации SOP к другим протоколам, а на основе уменьшения степень прозрачности. Например, SOP подразумевает, что есть какой-то глобальный агент и что можно отослать какое-то сообщение этого агента. И SObjectizer сам разошлет это сообщение во все имеющиеся коммуникационные каналы, которые пропускают это сообщение через свои фильтры. Вместо этого лучше, имхо, выделить конкретные прикладные сообщения (которые будут ходить по какому-нибудь XML-RPC или SOAP) в сообщения конкретного агента. А сам этот агент будет заниматься их получением, преобразованием в конкретный протокол и пр.
Что-то подобное мы у себя проделывали с подключением к SObjectizer приложению SOAP-клиентов (через gSOAP обрабатывались входящие запросы, которые как SObjectizer сообщения отсылались во внутрь системы на обработку) и при подключении SObjectizer-приложения наружу через XML-RPC.
Т.е. мне кажется более перспективным не натягивание SOP надругие типы транспорта, а на создание библиотек шлюзов между SObjectizer и другими приложениями через различные виды транспорта.
Вот как-то так. Сумбурно получилось. Если смогу сформулировать точнее, то допишу.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Аноним, Вы писали:
А>Подробно-подробно не читал, но хочется вкратце знать, чем это отличается от какого-нибудь MoM типа SonicMQ или TIBCO Randevouz?
Мне тоже
Не хватает времени на то, чтобы внимательно изучать все ссылки, которые мне присылают после публикации статьи о SObjectizer. Вот сейчас готовлю сравнение SObjectizer с FIPA Abstract Architecture. Документацию по TIB/Rendezvous выкачал, но еще не прочитал. Как только прочту, смогу сделать более тчательное сравнение.
Пока (обладая знаниями о TIB/Rendezvous на уровне небольшого обзора в "Распределенных системах" Таненбаума) могу сказать, что SObjectizer -- это в первую очередь инструмент для упрощения разработки многопоточных приложений в которых отдельные сущности можно представить в виде конечных автоматов (агентов). Сообщения в SObjectizer это просто механизм для организации взаимодействия между такими сущностями. Возможности создания распределенных приложений и выхода сообщений за границы процесса стали побочным эффектом первоначальной идеи. Хотя эффектом, который сразу был оценен по достоинству.
TIB/Rendezvous же является, в терминологии Таненбаума, системой согласования, в которой внимание как раз уделяется механизму коммуникации разных процессов, а уже организация самих процессов не является частью TIB/Rendezvous. Т.е. во главу угла в TIB/Rendezvous ставится информационная шина, в то время как в SObjectizer -- организация приложения (процесса) в виде набора агентов.
Нужно так же сказать, что для упрощения построения на основе SObjectizer распределенных приложений нами была разработана библиотека Message Box API (mbapi), которая в чем-то напоминает систему согласования. Эта библиотека так же будет выпущена как OpenSource продукт, но после выхода стабильной версии SObjectizer 4.4.
Если останавливаться на деталях TIB/Rendezvous, то можно сказать следующее:
Знание структуры сообщений
В TIB/Rendezvous сообщения являются самоописывающими, поэтому при получения сообщения можно определить его структуру. В SObjectizer разработчик изначально должен знать структуру сообщения, более того ему должен быть доступен, как минимум, h-файл с C++ описанием сообщения.
Адресация по теме и публикация сообщений
В TIB/Rendezvous при отсылке сообщения отправитель назначает сообщению тему. А если кто-то хочет получать сообщения, то он должен подписаться на эту тему. В общем-то подобная механика есть и в SObjectizer, только у нас все темы сообщений заранее определены (в виде пары <имя агента, имя сообщения>). А в TIB/Rendezvous при подписке на тему можно использовать символы заместители (вроде NEWS.comp.*.books).
Архитектура сети распространения сообщений
TIB/Rendezvous содержит специальные демоны (rendezvous daemon и rendezvous router daemon), которые отвечают за груповую и сквозную рассылку сообщений, а так же позволяют масштабировать систему TIB/Rendezvous в больших глобальных сетях. В SObjectizer нет такой продвинутой системы маршрутизации, все необходимые коммуникационные каналы нужно организовывать внутри приложения. Аналогом rendezvous daemon, вероятно, можно считать связку агента-коммуникатора с транспортными агентами, т.к. именно они отвечают за широковещательную и целенаправленную отсылку сообщений. Но вот средств маштабирования на глобальные сети, аналогичные rendezvous router daemon, SObjectizer не имеет. Да и исходя из его нынешнего предназначения они ему вряд ли нужны.
При установлении SOP соединений SObjectizer-процессы не обмениваются информацией о том, какие темы их интересуют (т.е. на какие темы есть подписка в каждом из агентов). Вместо этого в процессе handshake происходит обмен фильтрами, т.е. именами глобальных агентов, чьи сообщения можно отсылать в SOP канал.
Механизм диспетчеризации событий
По поверхностному описанию у Таненбаума механизмы обработки событий у SObjectizer и у TIB/Rendezvous очень похожи. Разве что терминология разная, поэтому трудно оценить, что же именно отличается не будучи знатоком TIB/Rendezvous. Таненбаум говорит о наличии разных очередей событий и об объединении нескольких очередей в группы очередей. А так же о возможности назначения группам приоритетов. Аналогичные вещи происходят в SObjectizer, только все это дело скрыто под ковром SObjectizer Run-Time. И очереди событий формируются автоматически для каждого агента, который получает событие. И автоматически обрабатываются в соответствии с приоритетами. А уж смешиваются ли очереди различных агентов зависит от типа агента (пассивный, активный, член активной группы).
Транзакционные сообщения
SObjectizer не поддерживает никакой транзакционной семантики. В самом SObjectizer, я считаю, она и не нужна. В mbapi была бы желательна, но пока не хватает ресурсов на ее реализацию.
Отказоустойчивость
SObjectizer не предоставляет средств по обеспечению оказоустойчивости. Опять таки это диктуется его изначальной природой. Если приложению требуется отказоустойчивость, то приложение должно само ее обеспечить. Создание средств, похожих на отказоустойчивые группы процессов в TIB/Rendezvous, в SObjectizer возможно. Но, скорее всего, это будет просто дополнительная библиотека (такая же как mbapi), а не встроенная в SObjectizer функциональность.
Защита
SObjectizer не имеет встроенных средств для огранизации защищенных каналов, работы с ключевой информацией, аутентификацией клиентов, котролем прав клиента и пр. Для организации защищенных SOP каналов можно использовать SSL соединения (есть дополнительная библиотека транспортных агентов, использующих OpenSSL). Работа с сертификатами отдается на откуп пользователю. Так же можно организовывать защищенные каналы путем их тунелирования посредством stunnel или ssh.
Вот такой беглый обзор. Надеюсь, со временем удасться сделать более углубленный.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, remark, Вы писали:
R>3. Состояния и агент являются монолитом. Агент находится сразу во всех состояниях по крайне мере в том смысле, что он должен содержать все данные, которые нужны всем его состояниям. Это плохо, т.к. (1) нелогично, (2) может привидить к ошибкам (когда агент обращается к своей переменной-члену, которая логически не имеет смысл в текущем состоянии агента, но физически она существует) и (3) может быть расточительно (данные одного состояния большие, но требуются очень редко). R>Хотелось бы видеть состояния, как отдельные объекты. Например:
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>3. Состояния и агент являются монолитом. Агент находится сразу во всех состояниях по крайне мере в том смысле, что он должен содержать все данные, которые нужны всем его состояниям. Это плохо, т.к. (1) нелогично, (2) может привидить к ошибкам (когда агент обращается к своей переменной-члену, которая логически не имеет смысл в текущем состоянии агента, но физически она существует) и (3) может быть расточительно (данные одного состояния большие, но требуются очень редко). R>>Хотелось бы видеть состояния, как отдельные объекты. Например:
E>Вот разказ о фреймворке, в котором что-то подобное сделано изначально: Реализация систем, управляемых событиями Использование конечных автоматов
Да, это то о чём, я говорил — классическая модель... Тока там нету механизма доставки/обработки сообщений Т.е. на фреймворк, на основе которого можно строить приложение, он не тянет, в отличие от subj.
А так, конечно, очень приятно, что есть средство автогенерации кода.
Спасибо за интересный вопрос.
K>Меня сильно мучает вопрос относительно скорости выполнения программ на SObjectizer.
Меня в последнее время тоже
Мы применяем SObjectizer для создания server-side приложений и его производительности хватает за глаза, поскольку есть гораздо более тормознутые составляющие.
Однако, при выпуске SObjectizer в свободное плавание оказалось, что вопрос накладных расходов SObjectizer всерьез никогда не рассматривался, т.к. SObjectizer никогда не был узким местом. Стыдно признаться, но на серьезное профилирование SObjectizer никогда не было времени, нужно было либо расширять возможности SObjectizer, либо создавать дополнительные околоприкладные библиотеки на его основе. Только сейчас, после выхода второй беты версии 4.4 на эту задачу выделено время.
Пока же предварительные замеры показывают следующее: на нутбуке Intel Pentium M 1.5GHz, 512Mb SObjectizer показывает пропускную способность в ~66K сообщений в секунду (под Windows XP и Visual C++ 7.1 и Slackware Linux 10.2 и GCC 3.3.2). Я уверен, что в SObjectizer будет найдено не одно узкое место и пропускную способность удасться повысить.
Тем не менее, в SObjectizer и приложениях на его основе нужно учитывать два фактора, которые оказывают самое прямое влияние на производительность:
1) сообщения передаются в виде динамически созданых объектов. Поэтому скорость создания, обработки и уничтожения сообщений напрямую зависит от эффективности выполнения new/delete. Пока от этого никуда не деться, можно только оптимизировать производительность за счет кастомизации операторов new/delete для некоторых C++ классов (как на уровне SObjectizer (и это одна из ближайших целей в его развитии), так и на уровне приложения);
2) SObjectizer был предназначен для разработки многопоточных приложений, отдельные части которых физически нуждаются в работе на отдельных нативных нитях. Посему в SObjectizer есть ряд мест, где требуется синхронизация доступа к разделямым между потоками структурам данных (системный словарь, счетчики ссылок на экземпляры сообщений и на агентов). Эта синхронизация доступа так же имеет свои накладные расходы, хоть при проектировании SObjectizer мы и стремились свести их к минимуму (но избавиться от них невозможно).
Наблюдения показывают, что производительноть SObjectizer мало зависит от общего количества агентов в системе. Так, производительность тестов с 300K агентов не сильно отличается от тестов с 3K агентов. Более важными факторами является количество активных агентов (активных групп агентов), количество заявок в очереди одного агента и количество таймерных заявок. Был случай, когда в системе оказалось зарегистрированными 10K агентов, каждый из которых выставил периодическую таймерную заявку на 10 секунд. Оказалось, что таймерные заявки генерировались быстрее, чем агенты успевали их разгребать (но здесь влияли не только накладные расходы самого SObjectizer, но и время обработки сообщения каждым из агентов, а оно было не маленьким, т.к. во время обработки велось логирование на диск). Эксперименты показали, что критический момент наступал где-то на границе 7K агентов.
K>Хотелось бы узнать об особенностях использования данного подхода в приложениях в критичным быстродействием K>(игр, например).
Я не сильно разбираюсь в программировании игр. И, насколько я понимаю, принципы работы шутеров в корне отличаются от, например, рилтаймовых стратегий. Я себе слабо представляю использование SObjectizer в шутере, а вот в стратегии реального времени -- вполне. Правда, я не знаю, достаточно ли для подобной стратегии скорости в 60K сообщений в секунду.
Может быть вы предложите какой-нибудь несложный имитационный тест, который мы бы попытались запрограммировать в SObjectizer и замерить его производительность? А затем бы опубликовали как результаты замеров, так и исходные тексты теста.
K>Спасибо
Вам спасибо за проявленный интерес.
Если не сложно, не могли бы вы сказать, откуда вы узнали про существование SObjectizer?
Если вы ознакомились с документацией/статьями о SObjectizer, то как вы находите их качество? Что, по вашему мнению, можно было бы улучшить?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Мы применяем SObjectizer для создания server-side приложений и его производительности хватает за глаза, поскольку есть гораздо более тормознутые составляющие.
Это вопрос.
Например, БД Oracle через oci может инсёртить ~100К записей в секунду (БД установлена на обычном ПК).
По сокету можно передавать ~40К сообщений в секунду в обе стороны одновременно (пробовал в обычной локалке Ethernet 100).
E>Пока же предварительные замеры показывают следующее: на нутбуке Intel Pentium M 1.5GHz, 512Mb SObjectizer показывает пропускную способность в ~66K сообщений в секунду (под Windows XP и Visual C++ 7.1 и Slackware Linux 10.2 и GCC 3.3.2). Я уверен, что в SObjectizer будет найдено не одно узкое место и пропускную способность удасться повысить.
15 мкс на одно сообщение на такой машине неплохо. Особенно, если учесть, что оптимизации ещё не было.
Вопрос: насколько увеличивается производительность при вертикальном масштабировании? Если на 3.0GHz будет ~132K, то это круто. Но возможен и такой вариант, что будет ~66K
Кажется ты говорил про создание маршрутизатора коротких сообщений на основе SObjectizer. Допустим требуемая пропускная способность 3К сообщений в секунду. Допустим на приём/обработку/отправку сообщения уходит 10 сообщений SObjectizer. Получается 30К/с. Т.е. 50% процессорного времени съедается фреймворком SObjectizer без выполнения какой-либо полезной работы. Т.е. собственно на приём/обработку/отправку сообщения остаётся 150 мкс. Не густо
Серверному приложению со средними требованиями по производительности такого быстродействия, в принципе, хватит. Но если говорить о приложениях с высокими требованиями, но это imho маловато.
E>Тем не менее, в SObjectizer и приложениях на его основе нужно учитывать два фактора, которые оказывают самое прямое влияние на производительность: E>1) сообщения передаются в виде динамически созданых объектов. Поэтому скорость создания, обработки и уничтожения сообщений напрямую зависит от эффективности выполнения new/delete. Пока от этого никуда не деться, можно только оптимизировать производительность за счет кастомизации операторов new/delete для некоторых C++ классов (как на уровне SObjectizer (и это одна из ближайших целей в его развитии), так и на уровне приложения);
Можно ещё попробовать посмотреть в сторону thread-local аллокаторов. Если не изменяет память, то кажется ты писал, что сообщение по окончании обработки удаляет тот поток, который его отправил. Соответственно скорее всего он его и создал.
E>2) SObjectizer был предназначен для разработки многопоточных приложений, отдельные части которых физически нуждаются в работе на отдельных нативных нитях. Посему в SObjectizer есть ряд мест, где требуется синхронизация доступа к разделямым между потоками структурам данных (системный словарь, счетчики ссылок на экземпляры сообщений и на агентов). Эта синхронизация доступа так же имеет свои накладные расходы, хоть при проектировании SObjectizer мы и стремились свести их к минимуму (но избавиться от них невозможно).
Советую смотреть в сторону lock-free структур данных. Это может существенно увеличить как скорость обработки, т.к. и масштабируемость при увеличении потоков.
А какие имеются разделяемые структуры?
Если очереди, то сам бог велел lock-free. Если несколько потоков кладут в очередь с одной стороны и один(несколько) берут с другой, то это может происходить практически без задержек и коллизий.
Если удастся поднять производительность на порядок, то SObjectizer можно будет ставить в один ряд с такими библиотеками как ACE
Здравствуйте, remark, Вы писали:
R>По сокету можно передавать ~40К сообщений в секунду в обе стороны одновременно (пробовал в обычной локалке Ethernet 100).
Теперь добавь сюда сохранение каждого принятого сообщения в БД и логирование факта его приема и цифра уменьшится на порядок
Кстати, какого размера были сообщения? Передавались ли они в синхронном или асинхронном режиме?
R>Кажется ты говорил про создание маршрутизатора коротких сообщений на основе SObjectizer. Допустим требуемая пропускная способность 3К сообщений в секунду. Допустим на приём/обработку/отправку сообщения уходит 10 сообщений SObjectizer. Получается 30К/с. Т.е. 50% процессорного времени съедается фреймворком SObjectizer без выполнения какой-либо полезной работы. Т.е. собственно на приём/обработку/отправку сообщения остаётся 150 мкс. Не густо
3K сообщений в секунду через обычный компьютер с надлежащей их обработкой -- это фанастика. Ведь в сутки это составляет ~260M сообщений. А в месяц больше 7 миллиардов сообщений. Любой оператор сотовой связи мечтал бы иметь такой трафик и возможность обслуживать этот трафик на одной персоналке средней мощности.
R> Если не изменяет память, то кажется ты писал, что сообщение по окончании обработки удаляет тот поток, который его отправил. Соответственно скорее всего он его и создал.
Не так. Сообщение удаляет тот поток, который последним его обрабатывал. Я не имею точной статистики, но, по моему предположению, это далеко не всегда отправивший сообщение поток.
R>Если удастся поднять производительность на порядок, то SObjectizer можно будет ставить в один ряд с такими библиотеками как ACE
Быстрее ACE быть не получится, ведь SObjectizer работает поверх ACE
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>По сокету можно передавать ~40К сообщений в секунду в обе стороны одновременно (пробовал в обычной локалке Ethernet 100).
E>Теперь добавь сюда сохранение каждого принятого сообщения в БД и логирование факта его приема и цифра уменьшится на порядок
Я же написал выше, что Oracle, стоящий на ПК, запросто сохраняет по 10К сообщений в секунду.
Зачем логировать при нормальной работе? Тем более, что сохраняем в БД. Мы логируем только, если есть подозрения на ошибки.
E>Кстати, какого размера были сообщения? Передавались ли они в синхронном или асинхронном режиме?
По 100 байт в синхронном режиме (через send/recv)
R>>Кажется ты говорил про создание маршрутизатора коротких сообщений на основе SObjectizer. Допустим требуемая пропускная способность 3К сообщений в секунду. Допустим на приём/обработку/отправку сообщения уходит 10 сообщений SObjectizer. Получается 30К/с. Т.е. 50% процессорного времени съедается фреймворком SObjectizer без выполнения какой-либо полезной работы. Т.е. собственно на приём/обработку/отправку сообщения остаётся 150 мкс. Не густо
E>3K сообщений в секунду через обычный компьютер с надлежащей их обработкой -- это фанастика. Ведь в сутки это составляет ~260M сообщений. А в месяц больше 7 миллиардов сообщений. Любой оператор сотовой связи мечтал бы иметь такой трафик и возможность обслуживать этот трафик на одной персоналке средней мощности.
А некоторые не только мечтают, но и заключают контракты на это
R>> Если не изменяет память, то кажется ты писал, что сообщение по окончании обработки удаляет тот поток, который его отправил. Соответственно скорее всего он его и создал.
E>Не так. Сообщение удаляет тот поток, который последним его обрабатывал. Я не имею точной статистики, но, по моему предположению, это далеко не всегда отправивший сообщение поток.
(пока что слегка поковырял Мнезию и xmerl).
