<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ryan, Ed,<div><br></div><div>Jay has been working on performance analysis for Seam.</div><div><br></div><div><blockquote type="cite">UIComponent$AttributesMap<br>-----------------------------------------------------<br>&nbsp;- Issues related to this were responsible for about 20% of the blocked threads<br>&nbsp;- Reported time spent blocked ranged from 30 ms - 848 ms with an average estimated to be 400ms<br>&nbsp;- I need to rerun the tests to be more specific.<br>&nbsp;- One of the items that was strange with this block was that it sometimes included completely unrelated actions or classes.<br>&nbsp;&nbsp; - after adjusting the filters, and rerunning the tests several times I was able to narrow it down.<br><br>* Investigation:<br>Unfortunately this issue is in the RI JSF implementation itself.&nbsp; The UIComponentBase implements its own Map (AttributeMap) ( see&nbsp;<a href="http://fisheye5cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponentBase.java?r=1.158#l1521" target="_blank">http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponentBase.java?r=1.158#l1521</a>).&nbsp; This is not an issue directly, but you will see calls to the "getAttributesThatAreSet" method in the get, put, and remove methods of the map.&nbsp; This is implemented in the UIComponent class ( see:&nbsp;<a href="http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponent.java?r=1.153#l1191" target="_blank">http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponent.java?r=1.153#l1191</a>).&nbsp; The real issue is the call to "this.getClass().getPackage();".&nbsp; This call will eventually synchronize in the "ClassLoader.getPackage" method on the "packages" object for the whole classloader.&nbsp; This is why other threads were also blocked on this - like org.jboss.seam.contexts.Contexts.isApplicationContextActive() which is accessing a ThreadLocal object.<br><br>We really have 3 options for this issue.&nbsp;&nbsp;<br>&nbsp;- We can work with the RI to get the handling of the package check changed so that the values are some how cached in the component - how often do packages change while running ;-)<br>&nbsp;- We can take a look and try to find excessive use of the components interactions with the AttributeMap.<br>&nbsp;- We do nothing - but keep an eye on JSF 2 to make sure items like this are handled better.</blockquote><div><br></div>Naively, I would assume it should be possible to cache the value of this.getClass().getPackage().</div><div><br></div><div>HTH,</div><div><br></div><div>Pete<br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>From: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">"Jay Balunas" &lt;<a href="mailto:tech4j@gmail.com">tech4j@gmail.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Date: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">24 September 2008 22:05:51 BST</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">"<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a>" &lt;<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Subject: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><b>[seam-dev] Some profiling of blocking threads</b></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> </div><div dir="ltr">I have been executing the 25 user performance tests through the profiler to identify hot spots and areas of concern.&nbsp; I am initially looking at our blocking threads, and behavior around them that is causing the problems. <br> <br>Test Description<br>--------------------<br>&nbsp;- Use the 25 user wiki forum front page jmeter tests discussed in the previous email.<br>&nbsp;- Uses same environment and procedures as defined in the previous email.<br>&nbsp;- Tests are executed through the profiler with CPU recording turned on.<br> &nbsp;- I have modified the default filters to allow the following packages<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - org.jboss.seam<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - javax.faces<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - most of the java.util collections and map classes<br><br>Profile Results<br>-------------------<br> This is not a complete analysis of the entire application or even all of the blocking threads - I will continue to work on them and feed more information back to list.<br><br>These items were detected via the thread usage history page, that shows all blocked and waiting threads and their stack traces.<br> <br>javax.naming.InitialContext.lookup<br>-----------------------------------<br>&nbsp; - as expected a large number of blocked threads were waiting or blocked while attempting to lookup the initial context.<br>&nbsp; - One interesting thing is that not all of these were blocked on a Hashtable - others were blocked on, or were related to calls to Properties and WeakHashMap objects.&nbsp; This is likely caused by further method invocations that have been filtered out.<br> &nbsp;&nbsp;&nbsp; - I will look further, but wanted to look at some of the other areas that were blocked.<br><br>UIComponent$AttributesMap<br>-----------------------------------------------------<br>&nbsp;- Issues related to this were responsible for about 20% of the blocked threads<br> &nbsp;- Reported time spent blocked ranged from 30 ms - 848 ms with an average estimated to be 400ms<br>&nbsp;- I need to rerun the tests to be more specific.<br>&nbsp;- One of the items that was strange with this block was that it sometimes included completely unrelated actions or classes.<br> &nbsp;&nbsp; - after adjusting the filters, and rerunning the tests several times I was able to narrow it down.<br><br>* Investigation:<br>Unfortunately this issue is in the RI JSF implementation itself.&nbsp; The UIComponentBase implements its own Map (AttributeMap) ( see <a href="http://fisheye5cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponentBase.java?r=1.158#l1521" target="_blank">http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponentBase.java?r=1.158#l1521</a>).&nbsp; This is not an issue directly, but you will see calls to the "getAttributesThatAreSet" method in the get, put, and remove methods of the map.&nbsp; This is implemented in the UIComponent class ( see: <a href="http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponent.java?r=1.153#l1191" target="_blank">http://fisheye5.cenqua.com/browse/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIComponent.java?r=1.153#l1191</a>).&nbsp; The real issue is the call to "this.getClass().getPackage();".&nbsp; This call will eventually synchronize in the "ClassLoader.getPackage" method on the "packages" object for the whole classloader.&nbsp; This is why other threads were also blocked on this - like org.jboss.seam.contexts.Contexts.isApplicationContextActive() which is accessing a ThreadLocal object.<br> <br>We really have 3 options for this issue.&nbsp; <br>&nbsp;- We can work with the RI to get the handling of the package check changed so that the values are some how cached in the component - how often do packages change while running ;-)<br> &nbsp;- We can take a look and try to find excessive use of the components interactions with the AttributeMap.<br>&nbsp;- We do nothing - but keep an eye on JSF 2 to make sure items like this are handled better.<br><br>org.ajax4jsf.application.AjaxViewHandler<br> --------------------------------------------<br>&nbsp;- This was not a large % of the blocked threads but caught my eye as a potential trouble spot because it seemed directly related to ajax calls.<br>&nbsp;- This was easier to track down and the root cause is in the org.ajax4jsf.application.ViewHandlerWrapper class.<br> &nbsp;- see <a href="http://anonsvn.jboss.org/repos/richfaces/trunk/framework/api/src/main/java/org/ajax4jsf/application/ViewHandlerWrapper.java" target="_blank">http://anonsvn.jboss.org/repos/richfaces/trunk/framework/api/src/main/java/org/ajax4jsf/application/ViewHandlerWrapper.java</a><br> &nbsp;- The problem is all the calls to "fillChain" which is a synchronized method in the class.<br>&nbsp;- We need to find out how often the "_initialized" field is false - is this once a request, once for each component, etc...<br> &nbsp;- it appears to be called many times - I will look further into this.<br><br>-------------------------------------<br>This is all I have had time for so far, but will continue to investigate some of the other aspects of the application.&nbsp; After completing the analysis of the primary blocking thread issues I will move on to other areas to profile.&nbsp; These will focus on specific issues raised by the team and the forums.&nbsp; I will also add performance tests and analysis for the dvd store example.<br> <br>Regards,<br>Jay<br><br clear="all"><br>-- <br>blog: <a href="http://in.relation.to/Bloggers/Jay" target="_blank">http://in.relation.to/Bloggers/Jay</a><br> </div> _______________________________________________<br>seam-dev mailing list<br><a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/seam-dev<br></blockquote></div><br></div></body></html>