1

Our application is having issue with rendering time on various part. We have been able to pin point the performance issue with a profiler (YourKit Java Profiler) within the JSF restoreView phase (lifecycle). Since, we use a lot of components in some pages the rendering of the tree must be the source of the problem. Some question on stackoverflow looks pretty much like what we are dealing. Also, we can see the same slow speed in dev and production.

Some specs:

  • MyFaces 2.1.7
  • javax.el 2.1.0

Profiler (CTRL+SCROLL to see details): enter image description here

We are trying to find solutions. So far, we came up with those:

  • Use less composition/components (which is not that great, because we liked to make generic component).
  • We could also go into JSF stateless mode.
  • Find the actual problem with JSF (IN DEEP).
  • Recently, we found out that some JUEL library (expression language) could greatly increase the rendering time.

I've been dealing with making JUEL works with Spring 3 (with OSGI). Here's the spec: JUEL 2.1.3.1 bundle (note: this bundle use a different version of javax.el than the one I use in my application will that cause clash?)

I have found another maven repo which only does Juel Implementation and a more recent version.

Update: Found a solution for javax.el clashing, since there was a lot of problems in the juel-api (because it's export his own javax.el) I modified the manifest with that line Fragment-Host: javax.el to eliminate it.

Is there a configuration/set up to enable better performance? Or, how to you actually configure JUEL with MyFaces and Spring?

Community
  • 1
  • 1
fneron
  • 1,057
  • 3
  • 15
  • 39
  • Could you post a basic example of a JSF page / managed bean that generates this problem? – Luiggi Mendoza Apr 05 '13 at 03:18
  • Which implementation of JSF do you use (Mojarra or Myfaces)? Is CPU used a lot or not during the slow responses? Is the JSF in development or production mode? (development mode is really-really slow as it does much more job during a request to be able to generate nicer messages). – Balazs Zsoldos Apr 05 '13 at 13:46
  • @Luiggi Mendoza : Unfortunatelly, it's not really something that I can "pin point" in the code since it's pretty big. I'll look how I can reproduce this on a lower scale. – fneron Apr 05 '13 at 14:12
  • @Balazs Zsoldos: Edited my answer. Will post the profiler output for cpu usage for restoreView (it's around 50-70%). – fneron Apr 05 '13 at 14:14
  • Sorry. I had some idea from before but none of them are the cause here. – Balazs Zsoldos Apr 07 '13 at 22:28

1 Answers1

3

I would say that the problem is caused by Spring Web Flow. I remember this issue SWF-1540. First check if you are using the right version (2.4.0.M1 or upper). Note personally I have not tested if that configuration has a performance issue, but I can say that MyFaces 2.1.7 an upper versions does not have any issues. It is known that some EL versions has perf issues, so try with juel or with apache EL (jasper-el, bundled with Tomcat).

As a personal opinion, watch out for Spring proxies, it is known that in some cases, when the pages are very big and complex, the proxies has a significant impact over performance. The suggested solution is use Apache OpenWebbeans, which is a very fast CDI implementation, optimized for those cases when you have a lot of beans interconnected.

You can check this article too "Understanding JSF 2 and Wicket: Performance Comparison" for tips about MyFaces performance.

You have to try by yourself what will work for your case, but I hope with these advices you can focus better your search.

lu4242
  • 2,318
  • 1
  • 15
  • 15
  • we have all the right version you mentionned. At the moment, we are struggling on setting up JUEL, we add it to the web.xml (with no errors), but when page render we can see in the console: MyFaces Bean Validation support enabled. (which means juel is not used...) – fneron Apr 09 '13 at 14:22
  • Allright. We have found something interesting by upgrading the javax.el 2.1.0 to 2.2.4. We noticed a great performance gain some actions before took 4 sec and now, about 300ms. Which is HUGE! Trying to find the release note to have a better idea of what actually got changed to have such a performance gain. – fneron Apr 09 '13 at 17:12