It would also be interesting to try different JSP page compilers, which would also make a huge difference - for example, Jasper2 (used in Tomcat 4.1.x) versus the original Jasper in Tomcat 4.0.
On the Sun JVM, one additional variable is to try the "-server" system property at startup time for your container. This selects the HotSpot mode optimized for long-running server applications, versus the default "-client" setting. Craig On Tue, 10 Sep 2002 [EMAIL PROTECTED] wrote: > Date: Tue, 10 Sep 2002 13:34:08 -0500 > From: [EMAIL PROTECTED] > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Cc: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > Subject: RE: Improving performance by splitting JSP? > > > Our test tag was using a HashMap. > > You can view this performance quirk yourself using Struts bean:message tag. > To get orders of magnitude in the performance discrepancy (to make sure we > were measuring the tag performance difference on a much more significant > scale than server access variance times) we went to 200,000 tag exectutions > done a variety of ways: > > One of our cases was a page with 20 tags, inside a loop 10,000 times. > Another case was same page, but done by 160 tags inside a 1250 loop. > Another case same page rendered by includes: page included another page 8 > times inside a 1250 loop. The included page had 20 tags. > > There were other varieties, but these three show the discrepancy in > performance with the increased number of tags very significantly. All > three cases output the same resulting html. All three cases executed the > tag code 200,000 times. The first and third cases, with 20 custom tag > occurrences, performed roughly the same (better performance). The second > case with 160 tags performed much much worse. I don't have our statistics > anymore, alas, but it was two or more orders of magnitude worse. We tried > an 80 tag variety as well, and it put the expected point on the slope > (significantly worse than same output rendered via 20 tags, not as bad as > 160 tags). > > Switching to IBM VM, or turning profiling flags on in the Sun VM before > running the tests, caused the performance discrepancy between these > approaches to vanish (roughly the better performance mark for all three). > > Be wonderful if someone else could verify on their own. Two days of > cursing over it was enough for us ;-). As soon as we realized we could fix > the problem pages by restructuring them into separate JSPs, we declared > victory over the Mystery of the VM ;-). > > Again this was 1.3, who knows if Sun's 1.4 vm still does this.... > > Jimbo > > Build a simple JSP that contains > > > > "Hajratwala, > Nayan (N.)" To: "'Struts Users Mailing >List'" <[EMAIL PROTECTED]> > <[EMAIL PROTECTED] cc: > m> Subject: RE: Improving performance >by splitting JSP? > > 09/10/2002 01:02 > PM > Please respond to > "Struts Users > Mailing List" > > > > > > > Was it a Hashtable or HashMap? > > It might be that since Hashtable is synchronized you were encountering a > bottleneck in your multithreaded environment, whereas just a regular loop > would not have this problem... > > --- > - Nayan Hajratwala > - Chikli Consulting LLC > - http://www.chikli.com > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 10, 2002 11:48 AM > To: Struts Users Mailing List > Subject: RE: Improving performance by splitting JSP? > > > > I had to go back and look at the test code we used, but yes - looks like we > did try a non-body tag. It did a hashtable lookup for whatever key values > was passed in as a parameter. I remember we found that we could only > recreate the performance discrepancy with tags that did some kind of memory > lookup; just adding loops around arithmetic statements are writing output > were tried, but did not exhibit the symptoms. > > Jim Weaver > Software Developer - ThoughtWorks > > > > > "Martin Cooper" > > <martin.cooper@tumb To: "'Struts Users > Mailing List'" <[EMAIL PROTECTED]> > leweed.com> cc: > > Subject: RE: Improving > performance by splitting JSP? > 09/09/2002 05:24 PM > > Please respond to > > "Struts Users > > Mailing List" > > > > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Monday, September 09, 2002 2:51 PM > > To: Struts Users Mailing List > > Subject: RE: Improving performance by splitting JSP? > > > > > > > > Yup, we looked at overall size of the JSP as well, and the > > association with > > performance was definitely number of bm/bw tags within a > > single JSP rather > > than overall JSP size. We even tried editing the generated > > servlet code > > and adding big unused methods to see if the problem had to do with > > generated servlet file size. That would kind've made sense, but was a > > negative. I believe we also tried a tag that just did a > > sysout rather than > > any kind of memory lookup (hashtable or properties file) and > > found that > > this performance quirk in the sun vm did not appear in that case. > > When you wrote your own tags (the message/write equivalents, I mean), did > you happen to play with body versus non-body tags? When I was wrestling > with > the "too many tags" problem a while ago, I ended up writing my own versions > of some of the Struts tags so that they were non-body tags, because they > caused noticeably less code to be generated. I didn't measure performance > differences, but I wouldn't be surprised to see a noticeable improvement > there too. > > -- > Martin Cooper > > > > > > We could never pin down a why, it seemed that the sun 1.3 vm > > just ran like > > a snail with a lot of bm or bw tags in a single page, so we > > stopped doing > > that ;-). Same number of tags split up into multiple JSPs, > > or a few tags > > called the same number of times via a loop - OK performance. > > > > It is very true also that splitting them up into smaller > > bites makes them > > more readable and maintainable, so it was a good solution all > > around. It's > > just that you are always nervous when you fix a problem and > > don't know the > > why of it ;-). > > > > Jimbo > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
