Re: как я бы стал писать такое приложение...ymikDecember 23 2006, 02:59:34 UTC
про адресацию сообщений в JMS: 1) есть сервер очередей 2) публикатор и подписчик создают соединение с сервером 3) публикатор создаёт выкладыват объект (message bean) в очередь, при этом указывая дополнительные параметры сообения (именно их я обозвал метками), присоединяя объект сообщения и указывая имя очереди. Формального создания очереди не требуется, достаточно при отправке указать имя. 4) подписчик подписывается на именную очередь. При этом в параметрах подписки он может указать фильтр по дополнительным параметрам письма (брать сообщения только с такими-то параметрами). 5) когда для этого подписчика появляется сообщение, то через интерфейс вызывается специальный метод куда передаётся объект сообщения.
Соответственно для каждого сообщения можно выставить приоритет доставки, если на одну очередь подписаны несколько подписчиков, то они будут получать сообщения по очереди.
-------
теперь про оценки эффективности: у нас есть человек, давай посчитаем, сколько задач он может породить: 1) он может сделать 1 ход в минуту - 1 задача 2) 1 задача по проверке онлайн/away статуса 3) по 1 задаче на каждый окружающий его предмет-персонажа в режиме боя на один его ход, допустим предметов 10, окружающих персонажей - тоже 10
всего получается всего получается 22 задачи в минуту на 1 персонажа. Ну оценим это число 30 задачами. Т.е. в среднем он будет генерировать 0.5 задачи в секунду. 100 боёв по 10 человек сгенерируют нам 500 задач в секунду + по 2 задачи для остальных 10000,т.е. это получится что-то типа 700 задач в секунду.
Количество сообщений таким образом можно оценить как 1500 в секунду. Для одного JMS сервера это многовато, да. Нормальный рабочий режим того же ActiveMQ - около 1000 сообщений всекунду. Но если распараллелить очереди по типам, скажем, на 3 сервера, то получится 500 и ещё нормальный запас по производительности. Несколько сложнее с JCache - скорее всего там нужно ставить уже кластер. Но тоже решаемо.
Причём - отметьте - я привожу реальные боевые данные для ActiveMQ, а Корбу никто даже и близко в хвост и гриву так не гонял по нескольку месяцев. У нас аудитория во много раз больше заявленных 10000, в секунду проходят порядка 5000 JMS сообщений (это когда нормальный рабочий режим, а когда какая-нибудь президентская линия случается - так там может на порядок больше...)
Теперь про ORB и её подспецификацию CORBA. ORB - это такой сферический конь в вакуме. По идее должно работать, но на самом деле очень специфично по вендорам и очень геморройно с точки зрения интерфейсов. Мало того, что в спеку включили нужное и ненужное, так ещё благодаря активнм действиям Борланда она была раздута до поистене монструозных размеров. Полностью ORB, по-иоему, ещё никто не реализовал - только усечённые варианты. Теперь только про CORBA. Та же причина - монструозность. Тот же RMI средствами JMX или WebService (между прочим, тоже стандарты ORB) выглядит куда яснее и понятнее, чем то количество проксей и условностей, которые призодится соблюдать в имплементации CORBA.
-------------- про чат: нет, чат не нужно делать через события: не вижу смысла прикручивать то, с чем прекрасно может справиться БД.
------------- про "Без четкого разделения кому направлено это сообщение не обойтись. Его должен получить один получатель." не понял - что имеется ввиду?
Re: как я бы стал писать такое приложение...oleg_buninDecember 23 2006, 03:08:27 UTC
Какая у Вас задача, можешь описать архитектуру приложения и задачи, которые оно решает?
Подсчет количества сообщений неверен. Один ход это не одна задача, а множество. В бою участвует в среднем большее количество людей. Задачи проверки статуса происходят несколько раз в минуту. Ну и, наконец, результаты надо раздать.
Возможно, результаты можно раздать с помощью JCache - это нечто вроде shared-памяти между десятком машин огромной емкости, я правильно понимаю?
PS: Про чат ты не прав, чат на 10 тысяч человек нельзя сделать на БД.
Re: как я бы стал писать такое приложение...ymikDecember 23 2006, 12:10:56 UTC
ИНФОН - это крупнейший контент-провайдер и агрегатор СМС услуг в России, Украине, Казакхстане, Беларуссии, Киргизии, Армении. Кроме того, являясь частью МонстерМоба работаем так же по всему миру - США, Англия, Германия, тихоокенаский регион, Израиль, Китай. У Монстермоба,фактически, два технологических (железячных) центра - в Китае и в России. В США тоже есть, но там не СРВ.
Чем занимается наша система? Мы держим очень много подключений к различнм операторам связи (если только по России - а это примерно треть наших подключений, то Билайн, Мегафон, МТС (причём зачастую подкючение не одно, а разбито по регионам и типу протоколов - для СМС одно, для Wap - другое, телетекст - третье, ММС - третье, USSD - четвёртое, тарификация WAP - пятое) и десятки мелких и региональных - Теле2, Мотив, Смартс, Скайлинк и т.д.). По России данные висят, например, здесь - http://agregator.ru/clients.phtml.
Есть так же у нас куча собственных СМС услуг + мы являемся агрегаторами для партнёров и контент-провадеров монстермоба. Подробнее об услуге СМС агрегатора можно прочитать тут - http://agregator.ru/services.phtml (картинка там, правда, уже год, как необновлялась, тепер ьмы работаем не только по HTTP).
----------------------------------
Теперь по поводу того, что мы делаем. Львиная доля - это обработка СМС запросов и PaidWAPа. На наши короткие номера (ИСНН) приходит СМС запрос. Мы получаем этот запрос из нашего соединения, роутим к услуге/партнёру по ИСНН, каналу и regexp текста сообщения, после чего, если это наша услуга - то сами обрабатываем, если нет - то отдаём партнёру. В конце, после отдачи ответа, может происходить дополнительная пост-обработка (но что именно мы там делаем - ком. тайна :).
Каждый шаг этого процесса логгируется - прежде всего для рассчёта с партнёрами и операторами (а биллинг может быть и как MO, так и МТ, то есть по факту получения запроса или по факту получения абонентом ответа от нас). Кроме того логгируется всё для сбора статистики, проведения маркетинговых исследований, поиска сбоя программ и просто неэффестивного использования системных ресурсов.
Каждая СМС порождает как минимум несколько сообщений по очередям: сам запрос, передача запроса от MessageGateway в роутер, внутренние очереди роутера (как раз та самая синхронизация модулей, что я описывал), очереди до наших сервисов, в случае если сервис отдаёт запрос куда-то на сторону (как брокер), то ещё одна очередь ожидания, потом образуются один или несколько ответов (ответов может быть много, если запрос инициировал рассылку + ответы могут быть разного типа - те же ММС, например), эти ответы тоже логгируются, потому что исходящие сообщения тоже платные и нужно будет выставить счёт партнёру, после чего на каждое отправленное сообщение в MG будут ещё приходить по два DeliveryStatus, которые мы должны тоже залогировать и передать партнёру. Итого на 1 сообщение с 1 ответом при передачи партнёру мы получаем от 16 до 24 сообщений в очередь.
Это не учитывая задачи иногда попридержать сообщения, чтобы они не зафлудили канал оператора или подключения партнёра, борьбу с фродом (очень "умных" людей, которые с помощью компа отсылают сразу по нескольку сотен СМС используя то, что биллинг операторов снимает деньги раз в полчаса). И это - только СМС траффик. С ПремиумВапом всё обстоит куда хитрее.
А теперь представье нагрузку на систему, особенно во время какой-нибудь прямой линии с президентом, танцах на льду или Евровидении. Когда ещё параллельно сыпятся обычныве запросы со всего мира и нельзя задержать их ни на минуту (как для тех же английских операторов - ответ должен быть дан не позднее, чем через N секунд после получения запроса).
Re: как я бы стал писать такое приложение...ymikDecember 24 2006, 01:09:39 UTC
обычо ответ должен быть в течении 5 минут. среднее время жизни пакета (со всеми статусами доставки) в нормальном режиме (без перегрузки системы, с одним ответом, со всеми статусами доставки) 20-40 секунд.
Re: как я бы стал писать такое приложение...ymikDecember 24 2006, 02:37:35 UTC
на порядок - это 2-4 секунды.
мой опыт чатов показывает, что пользователи готовы мирится с задержкой появления отправленного сообщения в 2-5 секунд (с учётом скидки на скорость соединения).
а для "ходов" пользователоя оптимальное время - 60 - 180 (а по другим данным даже 240) секунд. Если одно действие (без учёта фраз общения) укладывается в этот интервал, то всё нормально. Не надо забывать, что с точки зрения пользователя каждое его дествие делится на три категории: 1) мгновенная реакция (применительно к интерфейсу - если человек нажал накнопку, то кнопка "нажалась") 2) реакция подтверждения (вывелся диалог или сообщение, что вы нажали на кнопку) 3) реальный результат действия (человек ощутил конечный результат)
время между 1 и вторым не может превышать 8 секунд, время между вторым и третьим - не может превышать 2,5 минуты (потом он просто рассеивает своё внимание, забывая о слежке за результатом). Это средние параметры по тестам UI интерфейсам (у меня образование UI дизайнер, я по этом курсовую сдавал :))
Соответственно первые две реакции можно реализовать непосредсвенно методами JS а третью реакцию можно задержать до получения реального результата. Это из категории классики коньюгтивной психологии и создания УИ, типичным следствием этого закона является так называемый "эффект консоли", когда кажется, что с помощью hot key и консольных команд результат получается быстрее и легче, чем при использовании тех же контекстных меню, хотя по таймшитам получается один и тот же результат.
Re: как я бы стал писать такое приложение...oleg_buninDecember 24 2006, 04:10:50 UTC
А я сказал - на два порядка, то есть 0.2-0.4 секунды.
Я не думаю, что игра, в которой задержки в несколько секунд от действия до результата будет конкурентноспособной.
Примечательно, что Вы начали убеждать меня в том, что задержки - это нормально, а не рассказали о том, что на описанных Java-технологиях можно реализовать быстрый код. То есть обмен информацией между сотней абонентов с максимальным временным ограничением в одну секунду невозможен на JMS?
Re: как я бы стал писать такое приложение...ymikDecember 24 2006, 10:21:16 UTC
"Я не думаю, что игра, в которой задержки в несколько секунд от действия до результата будет конкурентноспособной."
цивилизацию помните?))) вы РТС делаете, аркаду, шутер или что-то иное?
да при прстой отправке сообщения в чат при плохом сондинении между самою отправкой и появлением сообщения на экране может пройти до 5 секуд! -------------------
"Вы начали убеждать меня в том, что задержки - это нормально" будте внимательны - я описывал задержки нашей системы, которая заточена под определённый набор действий (например на запись и хранение биллинговой статистики). -------------------
Теперь к вопросу о скорости. Вопрос-то задан некорректно - что эта за сотня, что они делают, как они обмениваются (длина, скорость постинга).
Если свести всё к вопросу чата между сотней абонентов, пишущих в осовном "ГЫ" и "ЛОЛ" каждые 2 секунды - то несомненно может, может и на порядок больше, тысячу таких: просто делаем рассылку и всё.
Ели нужны приватные адресные сообщения - то и в этом случае может - нужно поставить метки на сообщения, только по сравнению с общим чатом "все для всех" производительность снизится процента на 2.
Единственное - от XML-based протокола надо сразу же уходить, счастья от него не будет - но Mule, помнится, это уже умеет.
Подробнее сейчас не расскажу - только-только начал копаться в этой части. Но описание вашей проблемы подозрительно похоже на то, что ESB должно решать.
(и в качестве шага в сторону - посмотрите на Tuple Spaces, http://c2.com/cgi/wiki?TupleSpace - там есть не только java-реализации, так что есть шансы поиспользовать готовый код)
Re: как я бы стал писать такое приложение...drumrockDecember 25 2006, 10:37:01 UTC
Кстати, насчёт всех участников. А вы не думали разделять участников игры на динамические отдельно обрабатываемые группы в зависимости от текущего месторасположения, скажем? Это основательно сократит объём вычислений (и сообщений). Правда, придётся отдельно обрабатывать включение/исключение из такой группы.
1) есть сервер очередей
2) публикатор и подписчик создают соединение с сервером
3) публикатор создаёт выкладыват объект (message bean) в очередь, при этом указывая дополнительные параметры сообения (именно их я обозвал метками), присоединяя объект сообщения и указывая имя очереди. Формального создания очереди не требуется, достаточно при отправке указать имя.
4) подписчик подписывается на именную очередь. При этом в параметрах подписки он может указать фильтр по дополнительным параметрам письма (брать сообщения только с такими-то параметрами).
5) когда для этого подписчика появляется сообщение, то через интерфейс вызывается специальный метод куда передаётся объект сообщения.
Соответственно для каждого сообщения можно выставить приоритет доставки, если на одну очередь подписаны несколько подписчиков, то они будут получать сообщения по очереди.
-------
теперь про оценки эффективности:
у нас есть человек, давай посчитаем, сколько задач он может породить:
1) он может сделать 1 ход в минуту - 1 задача
2) 1 задача по проверке онлайн/away статуса
3) по 1 задаче на каждый окружающий его предмет-персонажа в режиме боя на один его ход, допустим предметов 10, окружающих персонажей - тоже 10
всего получается всего получается 22 задачи в минуту на 1 персонажа. Ну оценим это число 30 задачами. Т.е. в среднем он будет генерировать 0.5 задачи в секунду. 100 боёв по 10 человек сгенерируют нам 500 задач в секунду + по 2 задачи для остальных 10000,т.е. это получится что-то типа 700 задач в секунду.
Количество сообщений таким образом можно оценить как 1500 в секунду. Для одного JMS сервера это многовато, да. Нормальный рабочий режим того же ActiveMQ - около 1000 сообщений всекунду. Но если распараллелить очереди по типам, скажем, на 3 сервера, то получится 500 и ещё нормальный запас по производительности. Несколько сложнее с JCache - скорее всего там нужно ставить уже кластер. Но тоже решаемо.
Причём - отметьте - я привожу реальные боевые данные для ActiveMQ, а Корбу никто даже и близко в хвост и гриву так не гонял по нескольку месяцев. У нас аудитория во много раз больше заявленных 10000, в секунду проходят порядка 5000 JMS сообщений (это когда нормальный рабочий режим, а когда какая-нибудь президентская линия случается - так там может на порядок больше...)
Теперь про ORB и её подспецификацию CORBA. ORB - это такой сферический конь в вакуме. По идее должно работать, но на самом деле очень специфично по вендорам и очень геморройно с точки зрения интерфейсов. Мало того, что в спеку включили нужное и ненужное, так ещё благодаря активнм действиям Борланда она была раздута до поистене монструозных размеров. Полностью ORB, по-иоему, ещё никто не реализовал - только усечённые варианты. Теперь только про CORBA. Та же причина - монструозность. Тот же RMI средствами JMX или WebService (между прочим, тоже стандарты ORB) выглядит куда яснее и понятнее, чем то количество проксей и условностей, которые призодится соблюдать в имплементации CORBA.
--------------
про чат:
нет, чат не нужно делать через события: не вижу смысла прикручивать то, с чем прекрасно может справиться БД.
-------------
про "Без четкого разделения кому направлено это сообщение не обойтись. Его должен получить один получатель." не понял - что имеется ввиду?
Reply
Подсчет количества сообщений неверен. Один ход это не одна задача, а множество. В бою участвует в среднем большее количество людей. Задачи проверки статуса происходят несколько раз в минуту. Ну и, наконец, результаты надо раздать.
Возможно, результаты можно раздать с помощью JCache - это нечто вроде shared-памяти между десятком машин огромной емкости, я правильно понимаю?
PS: Про чат ты не прав, чат на 10 тысяч человек нельзя сделать на БД.
Reply
Чем занимается наша система? Мы держим очень много подключений к различнм операторам связи (если только по России - а это примерно треть наших подключений, то Билайн, Мегафон, МТС (причём зачастую подкючение не одно, а разбито по регионам и типу протоколов - для СМС одно, для Wap - другое, телетекст - третье, ММС - третье, USSD - четвёртое, тарификация WAP - пятое) и десятки мелких и региональных - Теле2, Мотив, Смартс, Скайлинк и т.д.). По России данные висят, например, здесь - http://agregator.ru/clients.phtml.
Есть так же у нас куча собственных СМС услуг + мы являемся агрегаторами для партнёров и контент-провадеров монстермоба. Подробнее об услуге СМС агрегатора можно прочитать тут - http://agregator.ru/services.phtml (картинка там, правда, уже год, как необновлялась, тепер ьмы работаем не только по HTTP).
----------------------------------
Теперь по поводу того, что мы делаем. Львиная доля - это обработка СМС запросов и PaidWAPа. На наши короткие номера (ИСНН) приходит СМС запрос. Мы получаем этот запрос из нашего соединения, роутим к услуге/партнёру по ИСНН, каналу и regexp текста сообщения, после чего, если это наша услуга - то сами обрабатываем, если нет - то отдаём партнёру. В конце, после отдачи ответа, может происходить дополнительная пост-обработка (но что именно мы там делаем - ком. тайна :).
Каждый шаг этого процесса логгируется - прежде всего для рассчёта с партнёрами и операторами (а биллинг может быть и как MO, так и МТ, то есть по факту получения запроса или по факту получения абонентом ответа от нас). Кроме того логгируется всё для сбора статистики, проведения маркетинговых исследований, поиска сбоя программ и просто неэффестивного использования системных ресурсов.
Каждая СМС порождает как минимум несколько сообщений по очередям: сам запрос, передача запроса от MessageGateway в роутер, внутренние очереди роутера (как раз та самая синхронизация модулей, что я описывал), очереди до наших сервисов, в случае если сервис отдаёт запрос куда-то на сторону (как брокер), то ещё одна очередь ожидания, потом образуются один или несколько ответов (ответов может быть много, если запрос инициировал рассылку + ответы могут быть разного типа - те же ММС, например), эти ответы тоже логгируются, потому что исходящие сообщения тоже платные и нужно будет выставить счёт партнёру, после чего на каждое отправленное сообщение в MG будут ещё приходить по два DeliveryStatus, которые мы должны тоже залогировать и передать партнёру. Итого на 1 сообщение с 1 ответом при передачи партнёру мы получаем от 16 до 24 сообщений в очередь.
Это не учитывая задачи иногда попридержать сообщения, чтобы они не зафлудили канал оператора или подключения партнёра, борьбу с фродом (очень "умных" людей, которые с помощью компа отсылают сразу по нескольку сотен СМС используя то, что биллинг операторов снимает деньги раз в полчаса). И это - только СМС траффик. С ПремиумВапом всё обстоит куда хитрее.
А теперь представье нагрузку на систему, особенно во время какой-нибудь прямой линии с президентом, танцах на льду или Евровидении. Когда ещё параллельно сыпятся обычныве запросы со всего мира и нельзя задержать их ни на минуту (как для тех же английских операторов - ответ должен быть дан не позднее, чем через N секунд после получения запроса).
Reply
Сколько секунд?
Reply
Reply
У нас ответ должен быть получен за время на два порядка меньше. Секунда будет катастрофой.
Reply
мой опыт чатов показывает, что пользователи готовы мирится с задержкой появления отправленного сообщения в 2-5 секунд (с учётом скидки на скорость соединения).
а для "ходов" пользователоя оптимальное время - 60 - 180 (а по другим данным даже 240) секунд. Если одно действие (без учёта фраз общения) укладывается в этот интервал, то всё нормально. Не надо забывать, что с точки зрения пользователя каждое его дествие делится на три категории:
1) мгновенная реакция (применительно к интерфейсу - если человек нажал накнопку, то кнопка "нажалась")
2) реакция подтверждения (вывелся диалог или сообщение, что вы нажали на кнопку)
3) реальный результат действия (человек ощутил конечный результат)
время между 1 и вторым не может превышать 8 секунд, время между вторым и третьим - не может превышать 2,5 минуты (потом он просто рассеивает своё внимание, забывая о слежке за результатом). Это средние параметры по тестам UI интерфейсам (у меня образование UI дизайнер, я по этом курсовую сдавал :))
Соответственно первые две реакции можно реализовать непосредсвенно методами JS а третью реакцию можно задержать до получения реального результата. Это из категории классики коньюгтивной психологии и создания УИ, типичным следствием этого закона является так называемый "эффект консоли", когда кажется, что с помощью hot key и консольных команд результат получается быстрее и легче, чем при использовании тех же контекстных меню, хотя по таймшитам получается один и тот же результат.
Reply
Я не думаю, что игра, в которой задержки в несколько секунд от действия до результата будет конкурентноспособной.
Примечательно, что Вы начали убеждать меня в том, что задержки - это нормально, а не рассказали о том, что на описанных Java-технологиях можно реализовать быстрый код. То есть обмен информацией между сотней абонентов с максимальным временным ограничением в одну секунду невозможен на JMS?
Reply
цивилизацию помните?))) вы РТС делаете, аркаду, шутер или что-то иное?
да при прстой отправке сообщения в чат при плохом сондинении между самою отправкой и появлением сообщения на экране может пройти до 5 секуд!
-------------------
"Вы начали убеждать меня в том, что задержки - это нормально"
будте внимательны - я описывал задержки нашей системы, которая заточена под определённый набор действий (например на запись и хранение биллинговой статистики).
-------------------
Теперь к вопросу о скорости. Вопрос-то задан некорректно - что эта за сотня, что они делают, как они обмениваются (длина, скорость постинга).
Если свести всё к вопросу чата между сотней абонентов, пишущих в осовном "ГЫ" и "ЛОЛ" каждые 2 секунды - то несомненно может, может и на порядок больше, тысячу таких: просто делаем рассылку и всё.
Ели нужны приватные адресные сообщения - то и в этом случае может - нужно поставить метки на сообщения, только по сравнению с общим чатом "все для всех" производительность снизится процента на 2.
Производительность ActiveMQ, как я уже сказал выше - около 1000 сообщений в секунду в синхронизированной очереди и около 1500 в рассылке. Есть и более производительные имплементации JMS - http://www.sonicsoftware.com/products/sonicmq/performance_benchmarking/index.ssp http://www.progress-tech.ru/products/sonic/mq
Reply
Reply
Reply
Reply
http://mule.mulesource.org/wiki/display/MULE/Home
Единственное - от XML-based протокола надо сразу же уходить, счастья от него не будет - но Mule, помнится, это уже умеет.
Подробнее сейчас не расскажу - только-только начал копаться в этой части. Но описание вашей проблемы подозрительно похоже на то, что ESB должно решать.
(и в качестве шага в сторону - посмотрите на Tuple Spaces, http://c2.com/cgi/wiki?TupleSpace - там есть не только java-реализации, так что есть шансы поиспользовать готовый код)
Reply
А на каких именно задачах так критично по скорости выходит?
Reply
Например, в бою. Собрать данные со всех участников, обсчитать и раздать.
Reply
Reply
Leave a comment