Re: [BeanUtils] Interesting Microbenchmarks
On Mon, 4 Aug 2003, Vic Cekvenich wrote: > Date: Mon, 04 Aug 2003 18:30:09 -0400 > From: Vic Cekvenich <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [BeanUtils] Interesting Microbenchmarks > > I think jPetStore is using DynaBeans and that is what they saw - > Reflection time. > I myself do not use DynaBeans (or think they are a good idea for a few > other reasons, like unit testing and reuse). > The problem with that theory is that DynaBeans do not use reflection -- they just wrap a HashMap with type safety checks. (And, at least in the limited microbenchmark I published, they are faster). > .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [BeanUtils] Interesting Microbenchmarks
Kurt,
You could always try Optimize It with it's 10-day evaluation.
http://www.borland.com/optimizeit/
It will tell you EVERYTHING you want to know, and is fairly painless to
setup. As long as you can gather your data within 10 days, it should
work just fine.
-jason
-Original Message-
From: Kurt Post [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 4:35 PM
To: Struts Developers List
Subject: RE: [BeanUtils] Interesting Microbenchmarks
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 (
and ) 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 h
RE: [BeanUtils] Interesting Microbenchmarks
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 (
and ) 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="" attribute. Finally,
> struts-html.tld was modified to make the ht
RE: [BeanUtils] Interesting Microbenchmarks
I stand corrected. Changing to Tomcat 4.1.x made a huge difference. With tomcat 4.0.3 pages rendering was taking more the 2 seconds during which CPU was pegged at 100%. After repeatedly reloading test pages, the CPU fan on my machine was running at hurricane speed. With Tomcat 4.1.24, page render times for all test pages were usually so fast that the displayed time came out at 0 ms (10 ms is the res of the system timer). The only difference between the page of html:checkbox tags vs. the page full of html:messages tags was that the html:checkbox page was a little bit more likely to show a render time of 10 ms which happened about one out of four times. The html:messages page showed a render time of 10 ms about one out of every 6 times. Looking at what the new JSP compiler cranks out it looks like its doing tag pooling now as well as optimizing generated code for the case when a BodyTagSUpport tag does not have any body content. Very cool, that's one less problem to worry about :) Kurt -Original Message- From: Kurt Post [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 5: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 ( and ) 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="" attribute. Finally, > struts-html.tld was modified to make the html:checkbox "property" > attribute > optional. > > Look
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 (
and ) 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="" 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 fas
Re: [BeanUtils] Interesting Microbenchmarks
I think jPetStore is using DynaBeans and that is what they saw - Reflection time. I myself do not use DynaBeans (or think they are a good idea for a few other reasons, like unit testing and reuse). .V Craig R. McClanahan wrote: The most important factor in page rendering time (which is not the same as the CPU consumption being discussed on the ServerSide thread) is the quality of the JSP page compiler. Tomcat 4.0.6 (your platform) uses the original version of Jasper, whereas the current generation (4.1.27 and 5.0.6) uses a completely rewritten "Jasper2". On some apps I'm familiar with, just this change resulted in 6x-8x improvements in rendering speed. The difference is startling, even in a single user environment. You're right ... reflection gets a bum rap when it gets blamed for long render times unless your CPU is maxed out. Even then, it's typically an insignificantly small factor in the big scheme of things. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 ( and ) 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="" 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 co
RE: [BeanUtils] Interesting Microbenchmarks
The most important factor in page rendering time (which is not the same as the CPU consumption being discussed on the ServerSide thread) is the quality of the JSP page compiler. Tomcat 4.0.6 (your platform) uses the original version of Jasper, whereas the current generation (4.1.27 and 5.0.6) uses a completely rewritten "Jasper2". On some apps I'm familiar with, just this change resulted in 6x-8x improvements in rendering speed. The difference is startling, even in a single user environment. You're right ... reflection gets a bum rap when it gets blamed for long render times unless your CPU is maxed out. Even then, it's typically an insignificantly small factor in the big scheme of things. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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="" 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 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
RE: [BeanUtils] Interesting Microbenchmarks
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="" 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 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
