Help coderanch get a
new server
by contributing to the fundraiser
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Seam performance problem of default code generated by seam-gen

 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In our project we used seam-gen to generate most of the code and then we started writing the business logic wherever necessary. The performance of the system was so poor that every request has to wait for 3 to 5 seconds(only to load 11 records at a time). To my astonishment I noticed that the code seam-gen generates is JSF-style code which accesses the backing bean many many times to render a page. As an example the method getResultList on the List class(extending EntityQuery) was accessed around 20 times to render a page. Each of these accesses are intercepted by the method interceptors of seam which adds to the delay. When I changed the default code to use a DataModel outjection by declaring a factory for generating the data model, things improved a lot. Why does seam-gen generate code that is inherently slow? Or is there some setting which I am missing here? What are the other ways to improve performance?
 
Ranch Hand
Posts: 259
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please read Dan Allen' s post http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.html
 
Author
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

To my astonishment I noticed that the code seam-gen generates is JSF-style code which accesses the backing bean many many times to render a page. As an example the method getResultList on the List class(extending EntityQuery) was accessed around 20 times to render a page. Each of these accesses are intercepted by the method interceptors of seam which adds to the delay.



Yes, you are absolutely correct here. The issue is that the method it is being intercepted on every invocation when displaying the data table. Because the getResultList may need to execute a query (if the results have not yet been loaded) it executes transactionally which requires interception.

When I changed the default code to use a DataModel outjection by declaring a factory for generating the data model, things improved a lot.



Yes, this is certainly one way to avoid the issue. Once the DataModel is outjected into the context there is no further need to invoke your component.

Why does seam-gen generate code that is inherently slow? Or is there some setting which I am missing here? What are the other ways to improve performance?



I have not seen performance issues as drastic as you have encountered with the seam-gen code, but as you noted, there is certainly room for improvement. As you mentioned, you can use a factory method with a context variable which is a common approach.

Another option is through the use of @BypassInterceptors. If you have a get method that is invoked that simply returns a value (nothing needs to execute transactionally and no dependencies need to be injected) you can avoid the interception by annotating your method with @BypassInterceptors. I use this quite frequently during performance tuning of my Seam applications.

To go beyond the basics and really increase performance and scalability, you can make use of caching. Seam provides a multi-layer caching approach that we cover in the book: Chapter 32. Improving Scalability with Multilayered Caching
 
Ashok C. Mohan
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have already read Dan Allens post and hence the improvements with outjection and factory. I was primarily perplexed at why seam-gen would generate code that could become quite slow. Sorry for the confusion.
 
Ashok C. Mohan
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply Jacob. I tried the @BypassInterceptors and it improves the performance a lot. I need to find all the methods that can be annottated with this. Currently I have only used jboss cache as hibernate second level cache. I tried using jboss pojo cache as the seam cache in the JSF templates. But unfortunately I found that the eviction of the cache on database updates is not automatic. It is quite cumbersome to manually evict the cache whenever the DB changes. But I did not know abot multi-layered caching provided by seam. I will definitely give it a look.
 
Hey! Wanna see my flashlight? It looks like this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/t/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic