EJB - 性能问题（有更多的 EJB 会影响性能）答案

【问题标题】：EJB - Performance issue (having more number of EJBs have effect on the performance)EJB - 性能问题（有更多的 EJB 会影响性能）
【发布时间】：2009-12-18 10:11:47
【问题描述】：

我们正在开发一个包含大约 400 个数据库表的应用程序。并且有相同数量的 EJB（都是本地接口，EJB 是无状态的），一个 EJB 通过@EJB 标签注入到另一个 EJB 中。

我的疑问是，拥有更多的 EJB 是否会对应用程序的性能产生影响？

【问题讨论】：

标签： jakarta-ee ejb-3.0

【解决方案1】：

配置和调整

您可能需要相应地调整系统大小。通常，每个 EJB 都有一个关联的池（但它是特定于应用程序的服务器，我只有 Glassfish 的经验）。因此，如果您有 400 个不同的 EJB，那可能代表了大量的对象。但所有这些都可以调整。

本地 EJB 调用

关于一个 EJB 调用另一个 EJB，我做了几次测试。这是我得到的结果。

是时候调用一个执行循环的 EJB了

Pojo:0 毫秒
本地 EJB：63 毫秒
同一个 EAR 中的远程 EJB：172 毫秒
另一个 EAR 中的远程 EJB：1735 毫秒

我得出的结论是，如果 EJB 相互调用是本地的，则它们不是性能问题。另见Is it worth to use POJO instead of EJB?。

部署和管理

EAR 的部署时间还取决于 EJB 的数量（解析注释、部署描述符等）。你可能会做一些测试来看看你的应用程序如何。服务器支持这样的部署。

监控应用。使用许多 EJB 可能会很快变得复杂，具体取决于应用程序。服务器。在 Glassfish 中，JMX 控制台和 Web 控制台并不能真正扩展到应用程序。有很多 EJB。比如我们感兴趣的EJB，有时需要在下拉列表中选择，当它们很多的时候不方便。

EJB/JPA 和 DAO

负责业务逻辑的 SLSB 应该是粗粒度的。你仍然可以为 DAO 使用细粒度的 SLSB。使用 JPA，DAO 现在非常精简，并且主要包含 JPA 查询。如果可能的话，尝试减少 DAO 的数量并让一些 DAO 负责多个表可能仍然很有趣。见JPA/EJB3 killed the DAO。

【讨论】：

谢谢 ewrnli。是的，我们计划每个表有一个 DAO，基本上这些 EJB 中存在的方法将只是创建/更新/selectById/selectAll 和删除。而且我们不会在另一个 SLSB 中注入（这些类型的基本 EJB）一个 SLSB。除此之外，我们还有一个执行业务逻辑操作的 EJB 层。我们将在执行业务逻辑的 EJB 中注入 SLSB（按表编写）。这是正确的吗？

【解决方案2】：

为什么每个表都有一个 EJB？ JPA 是通常与 EJB3 一起使用的持久性机制，JPA 注释的类不是 EJB。我倾向于用粗粒度的对象来表达我的 EJB 层。例如，Order 可能是一个 EJB，其接口用 OrderLines 表示，而 OrderLines 不是 EJB。

话虽如此，假设您正在对 EJB 使用本地调用，那么运行时开销不必过多。当您获得引用时，您需要支付 JNDI 查找的成本，并且容器在分派方法时需要做一些工作（考虑安全性和事务），因此必然会有一些开销，无论这对您的应用程序来说是否太多只有基准测试才能判断。

我的直觉：你拥有的 EJB 比你需要的多，你会因为更少的而快乐。

【讨论】：