Brendan I'm kind of on a low budget here and so I'm using NetBeans which as far as I can tell, doesn't have any profiling support. As soon as I got some spare time I was going to look into getting a profiler. I might also try out Eclipse to see what it has to offer.
Kurt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 7:07 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [BeanUtils] Interesting Microbenchmarks Kurt, Why don't you hit that thing with a profiler? When I hist a large number of logic:equal tags with a profiler I found an unexpected performance issue in CompareTagBase: if ((type < 0) && (value.length() > 0)) { try { doubleValue = Double.parseDouble(value); type = DOUBLE_COMPARE; } catch (NumberFormatException e) { ; } } I have a fix for this mostly complete but and need to get it finished before jstl makes it irrelevant. :) Brendan -----Original Message----- From: Kurt Post [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 2:47 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: RE: [BeanUtils] Interesting Microbenchmarks But doesn't the big speed improvement of switching from html:checkbox to html:messages kind of eliminate the tomcat differences. Both of these tags are BodyTagSupport tags and thus the JSP compiler generates the same code with only the object names and attribute names being different. If you have two different tag invocations ( <html:checkbox value="someval"/> and <html:messages id="junk"/>) and a page full of one of them renders 100 times faster then a page full of the other, can't you eliminate the app server as the cause for this difference? -----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 5:23 PM To: Struts Developers List Subject: RE: [BeanUtils] Interesting Microbenchmarks It would be more interesting if you ran the tests on the latest Tomcat production build because of the *large* JSP performance improvements between the 4.0.x and 4.1.x series. David --- Kurt Post <[EMAIL PROTECTED]> wrote: > I am creating a web app that has several survey pages where there are a > total of 120 or more radio buttons and check boxes on one page. I have > been > seeing average page render times on the order of 2 to 2.5 seconds (some > times as bad as 5 seconds) with a single user hitting the site. I was > going > to put off my investigation into this problem until the site was in a > more > finished form. But since this topic has come up and because I needed > something to keep me busy until I go on vacation Wednesday, I decided to > look into it now. > > After running some tests which I'll describe below, I'm starting to feel > like the performance problem reported in TheServerSide case study was > caused > by excessive garbage collection and not by the use of reflection to > display > and update form values. Also their choice to use incremental garbage > collection in their tests probably made the struts app look far worse > then > it would have if it had been run with standard garbage collection. > > Like others who have posted on this subject recently, my initial guess > was > that reflection was a likely cause of the performance bottleneck. But > there > was one thing that seemed to contradict my theory. While it was true > that > it took 2 seconds or more to render the page to the browser; when I > clicked > the submit button after checking all check boxes, the form bean was > updated > and the main page was rendered almost instantly. So I decided to figure > out > just how much time was being spent doing reflection. My testing showed > that > time spent on reflection to render the page was consuming so little time > that it couldn't even be measured. In my opinion, the big performance > problem is caused by garbage collection firing much more often then you > would expect. Perhaps making changes which reduce the number of objects > being created and destroyed for each tag invocation is the best way to > improve performance. > > > How I Tested For Time Spent On Reflection > ----------------------------------------- > > To prepare for the tests, I made two test JSP pages. Both pages > consisted > of 150 html:checkbox tags arranged in 15 rows with 10 checkboxes per > row. > The first test page contained html:checkbox elements with property > values > similar to "survey(questionName).selectedValues[5]". On the second test > page, I removed all property attributes from the html:checkbox elements > thus > leaving them with just a value="<some value>" attribute. Finally, > struts-html.tld was modified to make the html:checkbox "property" > attribute > optional. > > Looking at CheckboxTag.java and RequestUtils.java, you can see that if > the > "property" attribute is not supplied to the html:checkbox tag, then > "RequestUtils.lookup(pageCOntext, name, property, null)" in > CheckbopxTag.java will simply return the form bean which is retrieved > via a > call to pageCOntext.findAttribute(). The beanutils are never called if > property == null. > > So how much faster was the second test page (which did not use > reflection) > rendered then the first test page which did us e reflection? The time > difference was too small to be measured. Both test pages took anywhere > from > 2 seconds to six seconds to render with the average time being around > 3.2 > seconds. > > > So Reflection Wasn't The Problem - More Experiments To Get At The > Problem > ------------------------------------------------------------------------- > > With reflection eliminated, my next suspicion was that the app server > (tomcat 4.0.6 bundled with NetBeans 3.5) was the problem. I had read > that > many performance enhancements had been added since tomcat 4.0.6. > Looking at > the .java code produced by the JSP compiler, I could see room for > optimization but there was nothing that could explain the terrible page > rendering times I was seeing. > > So to test it out, I copied the second test page and replaced all > html:checkbox tags with html:messages tags. In the context of my test > page, > the html:messages tag would simply look for messages at > Globals.ERROR_KEY. > Since nothing would be found at that key, the tag would just render > nothing. > > This test page which had 150 html:messages tags on it typically rendered > in > 10 to 20 milliseconds. > > Finally just for the heck of it, I made a test JSP page which just > contained > 150 <input type="checkbox"...> tags. This page typically render in 0 to > 10 > milliseconds. > > > Effect Of Changing To Incremental Garbage Collection > ---------------------------------------------------- > > Up until now, all tests were performed with "java -server ...". By now > I > was getting convinced that the problem was that garbage collection was > happening every time one of the first two test pages were being rendered > and > that is what was killing the performance. Turning on GC logging > confirmed > that. So, I decided to turn on incremental garbage collection. Wow, > what a > difference. Things started taking twice as long! Looking at the GC > log, I > could see that the GC was firing pretty much constantly (like you would > expect) but that many of those incremental GC's were taking .2 to .9 > seconds. The result was much worse performance on the first two test > pages > and even the third test page (with html:messages tags on it was almost > twice > as slow. The last test page which just contained no struts tags except > for > html:form and html:submit still took from 0 to 10 milliseconds but I > thick > this was just due to limitations in accuracy of the system timer. > > > Test Environment > ---------------- > Intel P4 2.8 GHZ 512MB > Window XP > JDK 1.4.1.4.1_04-b01 > Tomcat 4.0.6 running under NetBeans 3.5 (normal execution, not debug) > Struts 1.1 > > > Kurt > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 02, 2003 5:37 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [BeanUtils] Interesting Microbenchmarks > > > TheServerSide (www.theserverside.com) recently published a case study > that > attempted to analyze the performance characteristics of a variety of > middleware configurations, including two J2EE app servers and > Microsoft's > .NET platform. One of the hot spots that showed up in the Java based > figures was identified as heavy use of reflection (the test app was > Struts > based and therefore uses commons-beanutils), but the report did not > detail > these findings. > > Despite the fact that the test condtions were very artificial (the > database was tuned in a way that it was never the hotspot, which is > unlike > virtually any high-use web application in production), it prompted a bit > of discussion over whether using reflection was a good idea. This in > turn > prompted me to write a couple of simple microbenchmarks to measure the > behavior of the most commonly used BeanUtils and PropertyUtils methods > for > copying sets of properties -- copyProperties() and populate(). > > Legend: > ====== > > "bean" - A plain old Java object (POJO) with eight properties, > one of each of the standard primitive types and one > String (org.apache.commons.beanutils.BenchBean) > > "dyna" - An instance of org.apache.commons.beanutils.BasicDynaBean > with exactly the same properties and types. The property > types for primitives in a DynaBean are the wrapper classes > such as java.lang.Integer. > > "map" - An instance of HashMap with eight entries pointing at > exactly the same values. The values for primitives > of the corresponding wrapper class types. > > "strs" - An instance of HashMap with eight entries pointing at > the same values, but all Strings (simulating request > parameters that are used to populate a form bean in Struts). > > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
