Здравствуйте, мне хотелось бы проконсультироваться на счёт возможности поднятия производительности системы.
Ситуация такова:
Имеется 80 тысяч пользователей, каждый в течении 5 минут должен обратиться к Web Service исполняемому на Weblogic 9.2.1 и получить результаты своего запроса. У каждого пользователя запущен агент написанный на VC++ который с периодичностью и обращается к веб сервису.
Проблема в том что сервер вешается в таком режиме работы. По-видимому по-причине большого количества запускающихся параллельных потоков.


Подскажите пожалуйста какие варианты решения данной проблемы могут быть ? Приветствуются любые идеи.

P.S. Картинка не отобразилась
Вот она
http://haxt.narod.ru/images/sit001.JPG

Здравствуйте, xserge, Вы писали:

X>Подскажите пожалуйста какие варианты решения данной проблемы могут быть ? Приветствуются любые идеи.

если позволяет сеть:
— перейти на асинхронные методы взаимодействия
— отказаться от протоколов на базе TCP, перейти на UDP

Здравствуйте, xserge, Вы писали:

X>Подскажите пожалуйста какие варианты решения данной проблемы могут быть ? Приветствуются любые идеи.

Смотри доки WebSphere на тему кластеризация. Читай также про Load Balancer.

Здравствуйте, Аноним, Вы писали:
А>Смотри доки WebSphere на тему кластеризация. Читай также про Load Balancer.

Аноним, т.е. это я был, имел ввиду WebLogic, а не WebSphere.

Также интересно, если будет кластеризация, посмотреть на Terracotta clustering.

Здравствуйте, xserge, Вы писали:

X>P.S. Картинка не отобразилась
X>Вот она
X>http://haxt.narod.ru/images/sit001.JPG
Трудно было на rsdn выложить???

Здравствуйте, xserge, Вы писали:

Написать пул потоков (Thread Pools) ... можно даже разграничить права т.е. высокий приоритет обрабатывается вне очереди и т.п.

Здравствуйте, xserge, Вы писали:

X>Здравствуйте, мне хотелось бы проконсультироваться на счёт возможности поднятия производительности системы.
X>Ситуация такова:
X>Имеется 80 тысяч пользователей, каждый в течении 5 минут должен обратиться к Web Service исполняемому на Weblogic 9.2.1 и получить результаты своего запроса. У каждого пользователя запущен агент написанный на VC++ который с периодичностью и обращается к веб сервису.
X>Проблема в том что сервер вешается в таком режиме работы. По-видимому по-причине большого количества запускающихся параллельных потоков.
X>http://haxt.narod.ru/images/sit001.JPG
X>Подскажите пожалуйста какие варианты решения данной проблемы могут быть ? Приветствуются любые идеи.
А что значит "вешается"? Судя по картинкам как CPU так и памяти ещё предостаточно? Может максимальное количество потоков в пуле подрутить. Они вон вроде все как закончились?

Здравствуйте, Stormblast, Вы писали:

S>Написать пул потоков (Thread Pools) ... можно даже разграничить права т.е. высокий приоритет обрабатывается вне очереди и т.п.

Ты, правда, думаешь что у J2EE сервера такой пул отсутствует?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Stormblast, Вы писали:

S>>Написать пул потоков (Thread Pools) ... можно даже разграничить права т.е. высокий приоритет обрабатывается вне очереди и т.п.

B>Ты, правда, думаешь что у J2EE сервера такой пул отсутствует?

В J2EE среде, вроде по спецификации, не рекомендуют запускать доп. потоки, а рекомендуют использовать пулы. — кажется так.
Пул потоков должен под лоджиком настраиваться.

Здравствуйте, Аноним, Вы писали:

B>>Ты, правда, думаешь что у J2EE сервера такой пул отсутствует?
А>В J2EE среде, вроде по спецификации, не рекомендуют запускать доп. потоки,
Примерно так.

А>а рекомендуют использовать пулы. — кажется так.
Не помню такого. По-моему в спеке написано что управление потоками полностью отдается на откуп серверу. Ну, и в ряде случаев предостерегают об ошибках в ассоциации данных с потоками по причине того что сервера приложений их пулируют

А>Пул потоков должен под лоджиком настраиваться.
Угу

Здравствуйте, xserge, Вы писали:

X>Имеется 80 тысяч пользователей, каждый в течении 5 минут должен обратиться к Web Service исполняемому на Weblogic 9.2.1 и получить результаты своего запроса. У каждого пользователя запущен агент написанный на VC++ который с периодичностью и обращается к веб сервису.
X>Проблема в том что сервер вешается в таком режиме работы. По-видимому по-причине большого количества запускающихся параллельных потоков.
Похоже на starvation какого-то ресурса: блокировки где-то в коде, пула соединений к базе, какого-нибудь кэша и т.п.

Профилируйте и ищите где блокируется.

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, xserge, Вы писали:

X>>Подскажите пожалуйста какие варианты решения данной проблемы могут быть ? Приветствуются любые идеи.

C0s>если позволяет сеть:
C0s>- перейти на асинхронные методы взаимодействия
C0s>- отказаться от протоколов на базе TCP, перейти на UDP

Очень интересная идея на счёт ассинхронного взаимодействия. Интересно а не прийдётся ли переписывать для этого клиента ? Очень дорого обойдётся инсталяция его по рабочим станциям. Я так полагаю что тут решающую роль может играть только периуд таймата на клиенте ? Остальное же возможно решить только переделкой веб сервиса. Или я не прав ?

Здравствуйте, xserge, Вы писали:

C0s>>- перейти на асинхронные методы взаимодействия

X>Очень интересная идея на счёт ассинхронного взаимодействия. Интересно а не прийдётся ли переписывать для этого клиента?

я уверен, что придётся — хоть и не знаю текущей логики
просто там, где нагрузка большая, лучше переосмыслить взаимодействие.
основной момент — что именно клиент в текущей модели ожидает в ответ на вызов веб-сервиса

X>Очень дорого обойдётся инсталяция его по рабочим станциям.

для инсталляций (если внтури предприятия) я бы давно предложил какую-то автоматизацию. хоть даже через ant, обновляющий через subversion-клиент snapshot зарелизенных jar-файлов. хотя можно и jnlp рассмотреть

X>Я так полагаю что тут решающую роль может играть только периуд таймата на клиенте?

решающую роль может играть отвязка клиента от синхронного ответа. но семантика без фактов — не ко мне

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, xserge, Вы писали:

X>>Имеется 80 тысяч пользователей, каждый в течении 5 минут должен обратиться к Web Service исполняемому на Weblogic 9.2.1 и получить результаты своего запроса. У каждого пользователя запущен агент написанный на VC++ который с периодичностью и обращается к веб сервису.
X>>Проблема в том что сервер вешается в таком режиме работы. По-видимому по-причине большого количества запускающихся параллельных потоков.
C>Похоже на starvation какого-то ресурса: блокировки где-то в коде, пула соединений к базе, какого-нибудь кэша и т.п.

C>Профилируйте и ищите где блокируется.
В коде нет блокировок, такой вариант не рассматривался и никак специально не программировался. Что то есть сомнения на счёт блокировок в базе. Пул соединений вообще никак не настраивался.

Веб сервис полностью синхронный.
асинхронность не реализована (((
Её реализация может как то помочь ?

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, xserge, Вы писали:

C0s>>>- перейти на асинхронные методы взаимодействия

X>>Очень интересная идея на счёт ассинхронного взаимодействия. Интересно а не прийдётся ли переписывать для этого клиента?

C0s>я уверен, что придётся — хоть и не знаю текущей логики
C0s>просто там, где нагрузка большая, лучше переосмыслить взаимодействие.
C0s>основной момент — что именно клиент в текущей модели ожидает в ответ на вызов веб-сервиса

X>>Очень дорого обойдётся инсталяция его по рабочим станциям.

C0s>для инсталляций (если внтури предприятия) я бы давно предложил какую-то автоматизацию. хоть даже через ant, обновляющий через subversion-клиент snapshot зарелизенных jar-файлов. хотя можно и jnlp рассмотреть

X>>Я так полагаю что тут решающую роль может играть только периуд таймата на клиенте?

C0s>решающую роль может играть отвязка клиента от синхронного ответа. но семантика без фактов — не ко мне

Спасибо за совет попробую как то реализовать асинхронное взаимодействие. Тем более в Веблоджике даже примеры такого есть.
На счёт развёртывания клиента по клиентам всё там уже автоматизировано и стандартизовано, но каждое развёртывание стоит кучи денег.

Здравствуйте, xserge, Вы писали:

X>Здравствуйте, мне хотелось бы проконсультироваться на счёт возможности поднятия производительности системы.
X>Ситуация такова:
X>Имеется 80 тысяч пользователей, каждый в течении 5 минут должен обратиться к Web Service исполняемому на Weblogic 9.2.1 и получить результаты своего запроса. У каждого пользователя запущен агент написанный на VC++ который с периодичностью и обращается к веб сервису.
X>Проблема в том что сервер вешается в таком режиме работы. По-видимому по-причине большого количества запускающихся параллельных потоков.
X>

X>Подскажите пожалуйста какие варианты решения данной проблемы могут быть ? Приветствуются любые идеи.

Если нужна производительность — нужно избавляться от XML и ВебСервисов. Другого пути нет.

Здравствуйте, denis_krg, Вы писали:

ну насчет xml — это вы погорячились , можно конечно и бинарный протокол (будет быстрее в разы),
но как уже сказали выше , есть и другие способы добиться производительности.
а для xml — легкие парсеры (sax, etc).

_>Если нужна производительность — нужно избавляться от XML и ВебСервисов. Другого пути нет.

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, denis_krg, Вы писали:

А>ну насчет xml — это вы погорячились , можно конечно и бинарный протокол (будет быстрее в разы),
А>но как уже сказали выше , есть и другие способы добиться производительности.
А>а для xml — легкие парсеры (sax, etc).

А Вы писали разборщики XML используя SAX? Если ХМЛ более-менее сложный это чрезвычайно трудоемкое занятие. Так что можно с чистой совестью говорить о том, что SAX-а для разработчиков бизнес-систем нет.

_>>Если нужна производительность — нужно избавляться от XML и ВебСервисов. Другого пути нет.

Да писал , иначе не говорил бы , нет смысла делать протокол межу клиентом и сервером слишком сложным (а речь как я понял именно об этом) , хотя
зависит от задачи конешно.


_>А Вы писали разборщики XML используя SAX? Если ХМЛ более-менее сложный это чрезвычайно трудоемкое занятие. Так что можно с чистой совестью говорить о том, что SAX-а для разработчиков бизнес-систем нет.

_>>>Если нужна производительность — нужно избавляться от XML и ВебСервисов. Другого пути нет.