Сколько удаленных клиентов EJB может обслуживать один сервер Java EE?

У нас есть ситуация, когда есть около 450 удаленных клиентов EJB, которым необходимо подключиться к серверу Java EE (контейнер OpenEJB 3.1.4). Нет HTTP-сервера.

Мы заметили, что после включения нескольких клиентов сервер начинает выдавать исключение javax.ejb.ConcurrentAccessTimeoutException.

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

Если значение высокое, мы получаем меньше ConcurrentAccessTimeoutExceptions, но многие клиенты просто начинают зависать там навсегда. Если значение низкое, создается множество исключений ConcurrentAccessTimeoutException.

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

Теперь, помимо этого, есть еще одна проблема. Каждый клиент постоянно опрашивает сервер с интервалом в 2 секунды. Мы можем изменить это поведение, но нам придется настроить архитектуру.

Есть ли исследование или кто-нибудь, кто имел опыт работы со многими клиентами, подключающимися к серверу Java EE?

Мы можем разработать дизайн для всего, что необходимо, но мы хотели бы иметь более конкретную цель.


numbers ejb jakarta-ee capacity
person Luis Soeiro    schedule 07.08.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

На StackOverflow может возникнуть сложный вопрос, поскольку в конечном итоге это проблема потоковой передачи, которая не имеет ничего общего с EJB. Вопрос более или менее идентичен следующему: «У меня есть код, который выполняется в синхронизированном блоке, сколько потоков я должен использовать и поддерживать быстроту?»

Настоящий вопрос заключается в том, что делает код в синхронизированном блоке? (т. е. @Stateful bean-компонент или @Lock(WRITE) метод @Singleton). Цель состоит в том, чтобы устранить необходимость в синхронизации или, по крайней мере, сократить продолжительность выполнения синхронизированного кода.

Есть конкретные способы получить эту информацию.

Одним из методов может быть увеличение тайм-аутов почти до бесконечности, а затем, когда что-то зависает, введите kill -3 12345 в командной строке, где 12345 — это идентификатор процесса сервера. Это приведет к тому, что дамп потока будет выложен на System.out сервера.

Этот вывод покажет вам, что именно делает каждый поток, какой метод он вызывает в данный момент и находится ли этот поток в состоянии ожидания. Вы захотите просмотреть этот вывод несколько раз.

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

person David Blevins    schedule 08.08.2012
comment
Ну, я надеялся на что-то вроде: нам удалось получить N клиентов с одним сервером... Мы обновились до OpenEJB 4, чтобы начать больше тестов. - person Luis Soeiro; 08.08.2012
comment
Да, точной цифры нет. Первый показатель — это сам код приложения. Если у него слишком много синхронизации, он не сможет масштабироваться независимо от того, какое оборудование вы на него набросите. После того, как это убрано, вторым наиболее важным фактором является количество ядер в сервере. Если вы хотите связаться со мной в автономном режиме, я был бы рад узнать, какие советы я могу дать вам по применению бесплатно. Обновление — это хорошо, но производительность не изменится, если приложение этого не позволяет. - person David Blevins; 09.08.2012