EJB - 性能问题（拥有更多EJB对性能有影响） [英] EJB - Performance issue (having more number of EJBs have effect on the performance)
问题描述
我们正在开发一个包含大约400个数据库表的应用程序。
并且具有相同数量的EJB（All是本地接口，EJB是无状态的），并且一个EJB通过@EJB标记注入到另一个EJB中。
We are developing an application with around 400 database tables. and have equal number of EJBs (All are Local interfaces and EJB is stateless) and one EJB is injected into another EJB by @EJB tag.
我怀疑是，是否有更多的EJB对应用程序的性能有任何影响？
My doubt is, is having more number of EJBs have any effect on the performance on the application?
推荐答案
配置和调优
您可能需要相应调整系统大小。通常，每个EJB都有一个关联的池（但它是app。服务器特定的，我只有Glassfish经验）。因此，如果您有400个不同的EJB，那么可能代表了大量的对象。但所有这些都可以调整。
You might need to size the system accordingly. Usually, each EJB has an associated pool (but it's app. server specific and I have only experience with Glassfish). So if you have 400 different EJB, that may represent a significant number of object. But all that can be tuned.
本地EJB调用
关于调用另一个EJB的EJB，我做了一次一些测试。这是我得到的结果。
Regarding an EJB calling another one, I made once a few tests. Here are the result I got.
调用一个执行循环的EJB的时间是10'000调用另一个辅助对象，该对象是：
Time to call one EJB that performs a loop with 10’000 call to another helper object which is either a:
- Pojo：0 ms
- 本地EJB：63 ms
- 同一EAR中的远程EJB：172 ms
- 另一个EAR中的远程EJB：1735 ms
- Pojo:0 ms
- Local EJB:63 ms
- Remote EJB in same EAR:172 ms
- Remote EJB in another EAR:1735 ms
我得出的结论是EJB调用每个如果他们是本地的，其他不是性能问题。另请参见是否值得使用POJO而不是EJB？。
I came to the conclusion that EJB calling each other is not a performance issue if they are local. See also Is it worth to use POJO instead of EJB?.
部署&管理
EAR的部署时间还取决于EJB的数量（解析注释，部署描述符等）。您可以进行一些测试以查看您的应用程序。服务器支持此类部署。
The deployment time of the EAR depends also of the number of EJB (to parse the annotations, the deployment descriptor, etc.). You might make a few tests to see how your app. server support such deployment.
监控应用程序。许多EJB可能很快变得复杂，具体取决于应用程序。服务器。在Glassfish中，JMX控制台和Web控制台无法真正扩展到应用程序。有很多EJB。例如，我们感兴趣的EJB需要在某个时间的下拉列表中选择，这在有很多它们时不方便。
Monitoring app. with many EJB can quickly become complicated depending on the app. server. In Glassfish, the JMX console and the web console don't really scale to app. with a lot of EJB. For instance, the EJB we are interested in need to be selected in a dropdown sometime, which is not convenient when there are a lot of them.
EJB / JPA和DAO
负责业务逻辑的SLSB应该是粗粒。您仍然可以使用细粒度的SLSB进行DAO。使用JPA，DAO现在非常精简并且主要包含JPA查询。如果可能的话，尝试减少DAO的数量并让一些DAO负责多个表可能仍然很有趣。请参见 JPA / EJB3杀死了DAO 。
SLSB responsible of the business logic should be coarse grained. You can still use fine-grained SLSB for DAO. With JPA, DAO are now really thin and contain mostly JPA queries. It might still be interesting to try to reduce the number of DAO and have some DAO responsible of more than one table, if that's possible. See JPA/EJB3 killed the DAO.
这篇关于EJB - 性能问题（拥有更多EJB对性能有影响）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
