Performance of RichFaces Filter and ui.pack.js
iradix Oct 29, 2010 3:24 PMI've recently started to profile two different JSF/Richfaces application using the New Relic profiler. Strangely, what I've found is the only resource that often takes more than 200ms to generate is the richfaces ui.pack.js file. A majority of the requests are fine, the average load time is around 100ms, but a small number are taking an unexpectedly long time. I couldn't tell you the number of times that specific file is requested but the larger of the two site averages around 50,000 page views a day and in the last 3 hours there have been about 40 requests for the ui.pack.js file that have taken longer than 2 seconds, 12 of those requests have taken longer then 30 seconds and the 3 longest took just over 2 minutes. I've tried to correlate the slow loads with cpu spikes or garbage collections and there doesn't seem to be a relation. I also don't see any other resources that are loading slower when it happens. Unfortunately part of being a "low impact" profiler means that the new relic tool only instruments certain classes, like ServletFilters, so the deepest level I can track the issue to is the org.ajax4jsf.Filter.doFilter() or a non filter method executing within it. I'm using Richface 3.3.2.SR1 with one application and 3.3.1.GA with the other and both are deployed to completely separate servers. The configuration that I think would be relevant is the same for both:
In web.xml
</context-param>
<context-param>
<param-name>org.richfaces.LoadStyleStrategy</param-name>
<param-value>ALL</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.LoadScriptStrategy</param-name>
<param-value>ALL</param-value>
</context-param>
<context-param>
<param-name>org.ajax4jsf.COMPRESS_SCRIPT</param-name>
<param-value>false</param-value>
</context-param>
In Seam components.xml
<web:ajax4jsf-filter enable-cache="true" force-parser="false"/>
I see that there is some locking that happens within RichFaces when resources are generated, could that be the cause? Has anyone else ever seen an issue like this?