Why is my Glassfish3.1.2.2/MyFaces2.1.9/JSF-managed performing better than TomEE1.5+/CDI-managed?

Question

I just migrated my web app from JSF managed beans to CDI managed beans, and I specifically wanted Tomcat or TomEE Plus to be the container of choice, because of the great things I heard about 'OpenWebBeans'. After deploying, configuring, and testing the TomEE 1.5+ / CDI-managed-beans web application, Full Page Refreshes are much much slower than Glassfish 3.1.2.2 / MyFaces 2.1.9 / JSF managed beans.

With Glassfish 3.1.2.2 / MyFaces 2.1.9 / JSF managed beans, full page refreshes only take 2 to 3 seconds.

With TomEE 1.5+ / CDI-managed-beans, full page refreshes take 5 to 10 seconds, and maybe even more than that at times. :(

Can you please tell me why is that?

Yesterday, prior to deploying the TomEE 1.5+ / CDI managed beans webapplication to the production server (Windows 2003 32-bit 4GB RAM and 1TB of diskspace), I read the following, which really did not answer my/this question at all:

glassfish v3 vs tomcat 7

I read that PPR is better on performance than FPR, but my session timeout/management implementation involved the following:

1. LoginFilter (servlet filter)

2. the following in h:head

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

Is CDI more (time) expensive than JSF managed beans, or is TomEE the container of choice for CDI? I know that JBoss (or Weld) is or has the reference implementation for CDI, so it may be best to consider JBoss/Weld.

Prior to completing the task of migrating from JSF-managed bean to CDI-managed bean (as well as migrating from Glassfish to TomEE), I had issues starting CDI-managed-bean web app on Glassfish/Weld.

Please answer the following questions above, and/or advise. Thanks.

Answer 1

As inidicated in the comments above, I am working with OpenEJB (TomEE) committers to resolve this issue. Personally, I feel the issue is possibly due to the following:

1. CDI managed beans defined and referenced in the app
2. Possible CDI cyclic references (which will possibly be resolved in CDI 1.1)
3. A really large CDI @SessionScoped bean, which references/injects many other CDI beans to accomplish business logic (or tasks) within the app
4. TomEE/OpenWebBeans (which is still under development)

So, the answer remains to be determined. I opened the following OpenEJB JIRA for this issue (URL below). Feel free to watch this JIRA, if interested.

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

UPDATE:

Now, TomEE/CDI-managed-beans is performing just as well as Glassfish/JSF-managed-beans on the production server, because I recently did the following:

1. replace frequently-used dynamic SQL with @entity named queries
2. added query hints to JPA createQuery() and createNamedQuery()
3. replaced frequently-used rendered="#{EL expression}" with new facelets and ui:include src="#{EL expression}", since TomEE committers advised that rendered="#{EL expression}" gets called 6 times.

So, my TomEE/CDI-managed-beans is now running on production server and I'm monitoring performance and enduser reports/experience.