为啥我的 Glassfish3.1.2.2/MyFaces2.1.9/JSF 管理的性能优于 TomEE1.5+/CDI 管理的性能？

Posted 2023-02-23

【中文标题】为啥我的 Glassfish3.1.2.2/MyFaces2.1.9/JSF 管理的性能优于 TomEE1.5+/CDI 管理的性能？

【英文标题】：Why is my Glassfish3.1.2.2/MyFaces2.1.9/JSF-managed performing better than TomEE1.5+/CDI-managed?为什么我的 Glassfish3.1.2.2/MyFaces2.1.9/JSF 管理的性能优于 TomEE1.5+/CDI 管理的性能？

【发布时间】：2012-11-12 14:25:32

【问题描述】：

我刚刚将我的 Web 应用程序从 JSF 托管 bean 迁移到 CDI 托管 bean，我特别希望 Tomcat 或 TomEE Plus 成为首选容器，因为我听说过有关“OpenWebBeans”的好消息。在部署、配置和测试 TomEE 1.5+ / CDI-managed-beans Web 应用程序后，整页刷新比 Glassfish 3.1.2.2 / MyFaces 2.1.9 / JSF 托管 bean 慢得多。

使用 Glassfish 3.1.2.2 / MyFaces 2.1.9 / JSF 托管 bean，整页刷新只需 2 到 3 秒。

使用 TomEE 1.5+ / CDI-managed-beans，整页刷新需要 5 到 10 秒，有时甚至更长。 :(

你能告诉我这是为什么吗？

昨天，在将 TomEE 1.5+ / CDI 托管 bean web 应用程序部署到生产服务器（Windows 2003 32 位 4GB RAM 和 1TB 磁盘空间）之前，我阅读了以下内容，这确实没有回答我/这个问题全部：

glassfish v3 vs tomcat 7

我读到 PPR 的性能优于 FPR，但我的会话超时/管理实现涉及以下内容：

LoginFilter（servlet 过滤器）

h:head 中的以下内容

meta http-equiv="refresh" content="#session.maxInactiveInterval;url=pf_viewExpired.jsf"

CDI 是否比 JSF 托管 bean 更（时间）昂贵，还是 TomEE 是 CDI 的首选容器？我知道 JBoss（或 Weld）是或有 CDI 的参考实现，所以最好考虑 JBoss/Weld。

在完成从 JSF 管理的 bean 迁移到 CDI 管理的 bean（以及从 Glassfish 迁移到 TomEE）的任务之前，我在 Glassfish/Weld 上启动 CDI 管理的 bean Web 应用程序时遇到了问题。

请回答以上问题，和/或提供建议。谢谢。

【问题讨论】：

这不是 JSF 特定的问题。

真的吗？所以 Glassfish、Tomcat、JSF-managed-beans 和 CDI-managed-beans 不是 JSF 特定的问题吗？我真的很喜欢 Glassfish-MyFaces-JSF-managed-beans 的性能，但我想迁移到 CDI，因为许多负责编写 JSF 规范的人建议所有人迁移到 CDI 以准备 JSF 2.2+，但迁移到 CDI使我的“JSF”网络应用程序“性能”变得更糟。此外，据我了解，Glassfish/Weld-for-CDI 的体验也不是很好。

CDI 是代理 bean，而 JSF 管理的 bean 是普通引用，预计 CDI bean 会慢一些，但从长远来看不会那么极端。你不能做一些分析（VisualVM、JProfiler 等）来看看在这 10 秒内花费最多的时间吗？

@ArjanTijms，感谢您的回复。我了解到 CDI 和 JSF 托管 bean 之间的性能肯定存在差异。我确实需要做一些分析，你是第二个推荐它的人；以前从未这样做过，所以很明显，现在是学习这样做的时候了。我与一些 OpenEJB 提交者保持联系，他们通过电子邮件向我提供一些建议，例如 'JSF' 渲染 =“...”，在 bean 中没有数据库访问权限（无论如何我“没有”这样做），等等...我将尽我所能消除对 JSF 渲染="..." 的使用。

我已经在生产服务器上使用了 jvisualvm（因为这是存在问题的地方并且可以复制），并且我一直在与 OpenEJB 提交者讨论这个问题。最近的讨论包括提到将 BeanA 注入 BeanB 和将 BeanB 注入 BeanA；这应该在CDI 1.1 - JSR 346 中解决；因此，我使用 MyFaces CODI BeanManagerProvider 来获取对 CDI bean 的引用，以避免嵌套 CDI 注入。希望这能解决我的这个问题。

【参考方案1】：

如上面的 cmets 所示，我正在与 OpenEJB (TomEE) 提交者合作解决这个问题。我个人觉得问题可能是由于以下原因：

在应用中定义和引用的 CDI 托管 bean 可能的 CDI 循环引用（可能会在 CDI 1.1 中解决） 一个非常大的 CDI @SessionScoped bean，它引用/注入许多其他 CDI bean 以在应用程序中完成业务逻辑（或任务） TomEE/OpenWebBeans（仍在开发中）

所以，答案还有待确定。我为此问题打开了以下 OpenEJB JIRA（以下 URL）。如果有兴趣，请随意观看此 JIRA。

TomEE 1.5.1 SNAPSHOT (and CDI beans) running slow on my production server

更新：

现在，TomEE/CDI-managed-beans 在生产服务器上的性能与 Glassfish/JSF-managed-beans 一样好，因为我最近做了以下事情：

将常用的动态 SQL 替换为 @entity 命名查询 为 JPA createQuery() 和 createNamedQuery() 添加了查询提示 用新的 facelets 和 ui:include src="#EL expression" 替换了常用的 render="#EL expression"，因为 TomEE 提交者建议调用 render="#EL expression" 6次。

所以，我的 TomEE/CDI 托管 bean 现在正在生产服务器上运行，我正在监控性能和最终用户报告/体验。

【讨论】：

大多数时候这是范围的问题。你真的在那个 bean 上使用了 CDI Scpes 吗？还是您只是删除了 javax.faces.bean.ManagedBean，使它们有效地被视为 CDI 的 @Dependent，因此它们为每个 EL 访问一遍又一遍地创建？给你一些想法：我使用这个堆栈每天提供多达 500 万次页面点击，并且平均页面的响应时间为 5 到 25 毫秒...