EJB - проблема с производительностью (большее количество EJB влияет на производительность) - PullRequest
Новая
       18

EJB - проблема с производительностью (большее количество EJB влияет на производительность)

3 голосов
/ 18 декабря 2009

Мы разрабатываем приложение с 400 таблицами базы данных. и имеют одинаковое количество EJB (все являются локальными интерфейсами, а EJB не имеет состояния), и один EJB внедряется в другой EJB с помощью тега @EJB.

Я сомневаюсь, влияет ли большее количество EJB-компонентов на производительность приложения?

Ответы [ 2 ]

10 голосов
/ 18 декабря 2009

Конфигурация и настройка

Возможно, вам придется изменить размер системы соответственно. Обычно каждый EJB имеет связанный пул (но это зависит от сервера приложений, и у меня есть только опыт работы с Glassfish). Так что, если у вас есть 400 различных EJB, это может представлять значительное количество объектов. Но все это можно настроить.

Местный вызов EJB

Что касается EJB, вызывающего другой, я провел несколько тестов. Вот результат, который я получил.

Время для вызова одного EJB, который выполняет цикл с 10'000 вызовами другого вспомогательного объекта, который является либо:

  • Pojo: 0 мс
  • Местный EJB: 63 мс
  • Удаленный EJB в том же EAR: 172 мс
  • Удаленный EJB в другом EAR: 1735 мс

Я пришел к выводу, что EJB, вызывающий друг друга, не является проблемой производительности, если они локальные. См. Также Стоит ли использовать POJO вместо EJB? .

Развертывание и администрирование

Время развертывания EAR зависит также от количества EJB (для анализа аннотаций, дескриптора развертывания и т. Д.). Вы можете сделать несколько тестов, чтобы увидеть, как работает ваше приложение. Сервер поддерживает такое развертывание.

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

EJB / JPA и DAO

SLSB, ответственный за бизнес-логику, должен быть грубым. Вы все еще можете использовать мелкозернистую SLSB для DAO. С JPA DAO теперь очень тонкие и содержат в основном JPA-запросы. Возможно, все еще будет интересно попытаться уменьшить количество DAO и поручить некоторым DAO более чем одну таблицу, если это возможно. См JPA / EJB3 убил DAO .

0 голосов
/ 18 декабря 2009

Зачем вам один EJB на стол? JPA - это механизм персистентности, обычно используемый с EJB3, аннотированные JPA классы не являются EJB. Я бы хотел выразить свой слой EJB в терминах более крупнозернистых объектов. Например, Order может быть EJB с интерфейсом, выраженным в терминах OrderLines, которые не являются EJB.

Сказав это, предполагая, что вы используете локальные вызовы к вашим EJB-компонентам, накладные расходы времени выполнения не должны быть чрезмерными. Вы платите стоимость поисков JNDI, когда получаете ссылки, и контейнеру нужно проделать небольшую работу при отправке метода (подумать о безопасности и транзакциях), так что неизбежно возникнут некоторые накладные расходы, слишком много ли для вашего приложения только бенчмаркинг может сказать.

Чувство моей интуиции: у вас больше EJB, чем вам нужно, и вы будете счастливее с меньшим количеством.

...