为什么我的Glassfish3.1.2.2/MyFaces2.1.9/JSF-managed表现优于TomEE1.5 /CDI-managed？

Question

我刚刚将我的web应用程序从JSF托管beans迁移到CDI托管beans，我特别希望Tomcat或TomEE Plus成为首选的容器，因为我听说“OpenWebBeans”非常棒。在部署、配置和测试TomEE 1.5/CDI managed beans web应用程序之后，整个页面刷新要比Glassfish 3.1慢得多。2.2/MyFaces 2.1。9/JSF托管bean。

与玻璃鱼3.1。2.2/MyFaces 2.1。9/JSF托管bean，整个页面刷新只需2到3秒。

使用TomEE 1.5/CDI管理的Bean，整个页面刷新需要5到10秒，有时甚至可能会更长(

你能告诉我为什么吗？

昨天，在将TomEE 1.5/CDI managed beans 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更（时间）昂贵，或者TOME是CDI的首选容器？我知道JBOSS（或CURE）是或有CDI的参考实现，因此最好考虑JBOSS/CURE。

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

请回答上述问题，并/或提出建议。谢谢

Answer 1

如上所述，我正在与OpenEJB（TOME）提交者合作解决这个问题。就我个人而言，我觉得这个问题可能是由以下原因造成的：

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

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

第1.5卷。1个快照（和CDI bean）在我的生产服务器上运行缓慢

更新：

现在，TomEE/CDI托管bean在生产服务器上的性能与Glassfish/JSF托管bean一样好，因为我最近做了以下工作：

1. 用@实体命名查询替换常用的动态SQL
2. 添加查询提示到JPA createQuery（）和createNamedQuery（）
3. 替换经常使用的渲染="#{EL表达式}"为新的facelets和ui：包括src="#{EL表达式}"，因为TomEE提交者建议渲染="#{EL表达式}"被调用6次。

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