JSF Central - Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude – Part 2
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude – Part 2
 
Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude – Part 2
(continued)
by Dan Allen
27 Mar 2009 01:30 EDT

In the second installment of this two-part article, Dan Allen continues his discussion of some common performance problems you may encounter when using JSF components, Seam components, and the EL. You'll learn about the set of best practices for eliminating them that led to an improvement of two orders of magnitude in the performance of his application.


Our Ajax responses are now lean and speedy. Better yet, these changes have had a favorable impact on server-side performance. Smaller ids, paths, and headers mean there is less for JSF to write into the output stream, resulting in better performance. Here are the timing results as we paginate from page-to-page in the data table using a page size of 50:

Request Elapsed time of request (ms) Time to render table (ms)
1 303 71
2 374 65
3 199 58
4 286 66
Avg 290.5 65

Now that's got some speed to it! In fact, the signal is smaller than the noise, so even if we were to make additional improvements, a hiccup in the network or an activity spike in the machine could cause more delay than the processing of the page. Compared to where we started back in part 1, the performance of the data table rendering has now improved by two orders of magnitude and the elapsed time of request-response cycle reflects an order of magnitude improvement.

I could recommend some other tips, but I'm really not sure how much of a difference they will make. Regardless, I will mention them.

Using Facelets in production mode

Facelets prides itself on offering instant change. It does this by looking for a new version of the template each time one is requested. If you are using a lot of templates to compose your page, you may suffer a slight performance hit from these scans. To eliminate the check, thus permanently fixing Facelets on the version of the template you have deployed (until another deployment), include the following context parameter in /WEB-INF/web.xml:

<context-param> <param-name>facelets.REFRESH_PERIOD</param-name> <param-value>-1</param-value> </context-param>

In my tests, though, I really can't measure the effect of this change. Even so, the advice I can give you is that the first time JSF builds a component tree, it does perform better if you make heavy use of Facelets compositions to group common markup, so the more include files, the better (surprisingly). In fact, don't be shy about using any of Facelets' templating features because they provide both developer and runtime optimizations.

Conclusion

The battle for performance is never over, but wve made significant progress. We improved the rendering of our pages containing a data table by two orders of magnitude, and gave the user a better experience by using partial page rendering rather than initiating a new request on every action. In addition, we trimmed down the size of the response so that the application still performs well over slow networks. Leveraging Seam's conversation scope sped up the response for result pages already viewed, and being careful about how components and context variables are referenced eliminated unnecessary overhead. But most important of all, we proved that JSF is capable of performing extremely well when used appropriately.

Resources



RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.