Martin,
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.
Thanks,
Mike
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čí
