-
1. Re: Seam performance concerns
mgrouch Jun 23, 2007 2:06 AM (in response to liudan2005)Can you change JSF setting to 'server' side state saving (in web.xml) and try the tests again? With myfaces and these suggestions
http://wiki.apache.org/myfaces/Performance
it had dramatic effect.
I haven't tried with Sun's JSF 1.2, but client side state saving should have negative impact on performance.
Are you using facelets? -
2. Re: Seam performance concerns
mgrouch Jun 23, 2007 2:12 AM (in response to liudan2005)Another thing:
JSF doesn't (in base components) let you to define a variable on a page.
So people quite often would write something like
#{hashMapBean[key].prop}
in many places on the page, which in fact leads to looking up hashMap many times + using reflection to access property.
JSF also has several (6) stages of processing the question and it operates on
a tree of JSF components on these stages which also slowing things down. -
3. Re: Seam performance concerns
mgrouch Jun 23, 2007 2:18 AM (in response to liudan2005)And in your case you should migrate to MyFaces 1.1.5 and Tomahawk 1.1.6.
MyFaces 1.1.3 is too broken anyway to be used in production.
It would be interesting to compare Myfaces 1.1.5 performance
vs Sun's JSF 1.2 (with server side state for both) and see who wins... -
4. Re: Seam performance concerns
liudan2005 Jun 23, 2007 3:49 AM (in response to liudan2005)Thanks for your reply. I am using server side states saving, and we don't have hashmap lookup in our pages.
We can't migrate to MyFaces 1.1.5 and Tomahawk 1.1.6 due to compatibility problem with seam 1.2.1. Also, MyFaces 1.1.5 doesn't work well with Seam 1.3. So basically we can't change our environment just yet. Sad! -
5. Re: Seam performance concerns
mgrouch Jun 23, 2007 10:43 AM (in response to liudan2005)Have you trieed Sun's JSF 1.2? Seam 1.3.0.A is pretty good and 1.3.0 should be out soon... You also should use facelets instead of JSPs.
Tomahawk immediate="true" helps a bit too on forms where you do not need validation. Hibernate caching should be used. Reduce number of complicated
EL expressions per page (cause they are evaluated using reflexion). Use AJAX, bit not over do it (for things which can be done purely on client side you should do it on client side). Use client side validation if you can.
Try to find out with http://facestrace.sourceforge.net/
which phase takes longest and try to improve it. Profiling should give better picture.
Reduce logging and IO.
Use java StringBuilder instead of StringBuffer. Minimize string concatenation,
and improve other string manipulations. -
6. Re: Seam performance concerns
mgrouch Jun 23, 2007 10:46 AM (in response to liudan2005)And local EJB interfaces vs remote ones to reduce serialization.
-
7. Re: Seam performance concerns
mgrouch Jun 23, 2007 10:54 AM (in response to liudan2005)And more ideas: Native IO on app server, JRockit JVM. Give JVM higher memory settings. Use factories for stateless objects such as DAOs (so they are created once and not repeteadly created/destroyed).
-
8. Re: Seam performance concerns
mgrouch Jun 23, 2007 11:08 AM (in response to liudan2005)Try using one transaction per page load (preferably with one EJB call in case of CMT). You might have to use wrapper transfer objects (which are considered not necessary nowadays) to wrap entities of different types.
This made big difference in my case. Do not forget to cache JNDI lookups.
See also other people experience here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=105674 -
9. Re: Seam performance concerns
stu2 Jun 23, 2007 7:10 PM (in response to liudan2005)I think you would want to run your app with a profiler and find out, empirically, where your app is spending its time. I think most commercial profilers have trial versions, and there are a variety of ways to do this.
Your app design based on Seam/JSF is no doubt quite different than it was with Struts. I suspect that when you compare two very well designed apps built with Seam and Struts, the Seam app will be somewhat slower. But not 10x. That sounds like an application issue. Beware of blindly trying things that "might improve performance." -
10. Re: Seam performance concerns
stu2 Jun 23, 2007 7:15 PM (in response to liudan2005)"mgrouch" wrote:
Use factories for stateless objects such as DAOs (so they are created once and not repeteadly created/destroyed).
...
Do not forget to cache JNDI lookups.
Again, you can certainly spend time doing this kind of stuff on the off chance that it will improve performance. More likely you'll find that in modern JVMs, object creation for short lived objects is essentially free, and JNDI lookups (btw, you're using Seam, right? Where are you directly interacting with JNDI anyway?) aren't going to be significant.
Spend some time with a profiler an find out what's going on. It's irrefutable, and will show you where you should spend effort optimizing. You may find that there are performance issues with Seam. You'll also find that if you can clearly show the issue, the Seam team will be extremely responsive in addressing these. -
11. Re: Seam performance concerns
lowecg2004 Jun 25, 2007 10:35 AM (in response to liudan2005)What are your config values for Ajax4Jsf's 'forceparse' in web.xml and Seam 'debug' in components.xml: <core:init debug="false" >?
I believe that by default, every request is routed through a Tidy filter, even for non-Ajax pages. forceparse = false will ensure that only Ajax requests go through the tidy process.
Make sure debug = false as Seam will reload pages.xml and other resources on each page request which on my machine adds 50ms or so to each request.
Between the struts and seam scenarios I assume you are using the identical JVM versions/parameters? -
12. Re: Seam performance concerns
mgrouch Jul 24, 2007 3:56 PM (in response to liudan2005)How do I set ajax4jsf forceparser to false with Seam 2.0?
There used to be ajax4jsf filter but not anymore.
I want to disable ajax4jsf tidying up output on each request.
With older Seam version I could do this...+ <filter> + <display-name>Ajax4jsf Filter</display-name> + <filter-name>ajax4jsf</filter-name> + <filter-class>org.ajax4jsf.Filter</filter-class> + <init-param> + <param-name>forceparser</param-name> + <param-value>false</param-value> + </init-param> + </filter>
-
13. Re: Seam performance concerns
junkie Jul 24, 2007 4:30 PM (in response to liudan2005)@mgrouch:
How do you cache JNDI lookups?
I only have this in my components.xml. What would I have to add? Thanks!<core:init jndi-pattern="nmp/#{ejbName}/local" debug="true"/>
-
14. Re: Seam performance concerns
gavin.king Jul 24, 2007 4:31 PM (in response to liudan2005)Look at web-2.0.xsd