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

Question

我刚刚将我的网络应用程序从JSF托管bean迁移到CDI托管bean，我特别希望Tomcat或TomEE Plus成为首选容器，因为我听说过“OpenWebBeans”。在部署，配置和测试TomEE 1.5+ / CDI托管bean Web应用程序之后，Full Page Refreshes比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托管bean，整页刷新需要5到10秒，有时可能甚至更多。 ：（

你能告诉我为什么会这样吗？

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

glassfish v3 vs tomcat 7

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

1. LoginFilter（servlet过滤器）

2. 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应用程序的问题。

请回答上述以下问题，和/或提出建议。感谢。

Answer 1

正如上面的评论中所述，我正在与OpenEJB（TomEE）提交者一起解决此问题。就个人而言，我觉得问题可能是由于以下原因：

1. 在应用
中定义和引用的CDI托管bean
2. 可能的CDI循环引用（可能在CDI 1.1中解决）
3. 一个非常大的CDI @SessionScoped bean，它引用/注入许多其他CDI bean来完成应用程序中的业务逻辑（或任务）
4. 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托管bean一样，因为我最近做了以下事情：

1. 使用@entity命名查询替换常用的动态SQL
2. 向JPA createQuery（）和createNamedQuery（）
添加了查询提示
3. 用新的facelets替换了经常使用的render =“＃{EL expression}”和ui：include src =“＃{EL expression}”，因为TomEE提交者建议调用render =“＃{EL expression}”6次。

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