myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Concini <>
Subject Re: Myfaces vs. mojarra restore view performance
Date Mon, 02 Aug 2010 17:19:34 GMT

We've been seeing some similar bottlenecks in our testing on Websphere.  
We've think we have it isolated down to where the largest portion of the 
impacts are coming from checkResourceExists() in 
DefaultViewHandlerSupport and DefaultRestoreViewSupport.  The problem, 
at least in our testing, is because they both call 
ExternalContext.getResource(), which subsequently calls into 
ServletContext.getResource().  This method has to make an expensive file 
system check to see if the file exists prior to returning the URL.  The 
penalty is even worse if the resource is in a jar since you have to 
crack open the jar.

I'm currently working on a simple caching solution that in initial 
testing has resulted in a very large reduction in average response time 
but its still a work in progress.  I'm waiting on further profiling from 
our performance team.  I'll have to check with legal to see what I'm 
allowed to disclose as far as numbers due to this testing being on 
pre-release WAS builds.  Either way, once I get some more testing 
results from our performance guys and do some regression testing I can 
upload a patch for you to try out with your tests to see what 
improvements you get with the caching.  I should have something later 
this week.


On 8/2/2010 12:44 PM, Martin Koci wrote:
> Hi,
> our profiling results show that myfaces are significantly slower in
> restore view phase:
> com.sun.faces.... LifeCycle .. restoreView : 80 ms
> o.a.m.RestoreViewExecutor : 750ms!
> This result is perfectly reproducible in our case. I profile it on a
> application real application  - I cannot post test case here.
> Configuration: myfaces or mojarra from trunk, partial state saving, a
> view with more than 200 UIInput components.
> Is it a known problem? I will provide more detailed profiling results
> later.
> Regards,
> Martin Kočí

View raw message