EJB - 性能問題（具有更多EJB數量會影響性能）

Question

我們正在開發一個包含大約400個數據庫表的應用程序。 並且具有相同數量的EJB（所有都是本地接口，EJB是無狀態的），並且一個EJB通過@EJB標籤注入到另一個EJB中。

我的疑惑是，有更多數量的EJB對應用程序的性能有什麼影響？

Answer 1

配置和調整

您可能需要尺寸的系統相應。通常，每個EJB都有一個關聯的池（但它的應用程序服務器特定，我只有Glassfish的經驗）。所以如果你有400個不同的EJB，那可能代表了大量的對象。但所有這些都可以調整。

本地EJB調用

對於一個EJB調用另一個之一，我曾經做了一些測試。這是我得到的結果。

時間來調用執行與10000通話循環到另一個輔助對象既不是一個一個EJB：

• POJO的：0毫秒
• 本地EJB：63毫秒
• 遠程EJB在同一EAR：172毫秒
• 在另一個EAR遠程EJB：1735毫秒

我來到那個EJB調用對方的結論是不是PERFORMA如果他們是本地的話，他們會問題。另見Is it worth to use POJO instead of EJB?。

部署&給藥

耳朵的部署時間還取決於EJB的數量（解析註釋，部署描述符等）。你可以做一些測試來看看你的應用程序。服務器支持這種部署。

監控應用程序。隨着應用程序的不同，許多EJB可能會很快變得複雜。服務器。在Glassfish中，JMX控制檯和Web控制檯並沒有真正擴展到應用程序。擁有大量的EJB。例如，我們感興趣的EJB需要在下拉列表中選擇，這在很多時候並不方便。

EJB/JPA和DAO

SLSB負責業務邏輯應該粗粒度。您仍然可以使用細粒度的SLSB進行DAO。使用JPA，DAO現在非常簡單，主要包含JPA查詢。如果可能的話，嘗試減少DAO數量並讓一些DAO負責多個表格可能仍然很有趣。請參閱JPA/EJB3 killed the DAO。

Answer 2

爲什麼每個表有一個EJB？ JPA是通常用於EJB3的持久性機制，JPA註釋的類不是EJB。我傾向於用較粗粒度的對象來表達我的EJB層。例如，Order可能是一個EJB，其接口用OrderLines表示，而不是EJB。

話雖如此，假設您正在使用本地調用您的EJB，運行時間開銷不需要太多。在獲取引用時，您需要支付JNDI查找的成本，並且在調度方法（考慮安全性和事務）時容器需要做一些工作，所以一定會有一些開銷，無論是對於您的應用程序來說太多了只有基準可以說明。

我的直覺：你擁有的EJB比你需要的多，你會更快樂。