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比你需要的多，你会更快乐。