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

0
votes

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.

1
javajsfglassfishcdiopenejb
This is not a JSF specific question. – Luiggi Mendoza
Really? So Glassfish, Tomcat, JSF-managed-beans, and CDI-managed-beans are 'not' a JSF specific question? I really love the performance of Glassfish-MyFaces-JSF-managed-beans, but I want to migrate to CDI, as many responsible for writing the JSF spec is recommending all to migrate to CDI in preparation for JSF 2.2+, but migrating to CDI is making my 'JSF' web app 'perform' much much worse. Also, Glassfish/Weld-for-CDI is not a good experience, from what I understand. – Howard
CDI being proxied beans and JSF managed beans being plain references, it's expected that CDI beans are a little slower, but not that extreme by a long shot. Can't you do some profiling (VisualVM, JProfiler, etc) to see where most time is spent during those 10 seconds? – Arjan Tijms
@ArjanTijms, thanks for that response. I am learning that there is definitely a difference in performance between CDI and JSF managed beans. I do need to do some profiling, you are the 2nd person that recommended that; never did that before, so evidently, now is the time to learn to do just that. I am in contact with a few of the OpenEJB committers, and they are advising me via email on some things like 'JSF' rendered="...", no database access in beans (which i am 'not' doing anyway), etc... I'm going to start eliminating use of JSF rendered="..." to the best of my ability. – Howard
I have already used jvisualvm on production server (since that is where the issue exists and can be duplicated), and I have been discussing this with OpenEJB committers. Discussion recently included mention of injection of BeanA into BeanB and injection of BeanB into BeanA; this is supposed to be resolved in CDI 1.1 - JSR 346; so, I am using MyFaces CODI BeanManagerProvider to get reference to CDI beans to avoid nested CDI injections. Hopefully, this resolves this issue of mine. – Howard

1 Answers

0
votes

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.