glad the suggestion helps. I firmly believe in profiling code to make sure simple little mistakes that appear harmless aren't killing performance.
I'm constantly amazed at how little things improve performance. the benefit of using OptimizeIt or any other good profiling tool is well worth it. that's my biased perspective :) peter lin --- Allistair Crossley <[EMAIL PROTECTED]> wrote: > This evening I did the same with JProbe under 360 > requests as you describe and this led to me gaining > a 38% speedup. > > The main bottleneck I found was some very simple > tags I have were calling out.flush() at the end. > Thiw was consuming 14 seconds of time to flush 1 > string from the tag. The tag is called many times > within our JSPs because it calls the current skin > label. > > By simply removing the flush call the tag call > method time across the load test went down to 2s. > Not bad hey. There were other areas which I solved > with application scope caching and a bean pool for a > 3rd party bean that takes ages to initialise a > connection. > > I am getting there slowly but surely but Yoav I > think was right all along and it is the code and you > have to profile it and examine those call graphs!!! > > ADC > > -----Original Message----- > From: Peter Lin [mailto:[EMAIL PROTECTED] > Sent: Mon 12/04/2004 19:53 > To: Tomcat Users List > Cc: > Subject: Re: Tomcat performance issue? > > > > > luckily I have a license of Borland OptimizeIt. > > What I do is I start tomcat using OptimizeIt. Then > I create a test plan in JMeter. Once tomcat is > running, I warm it up by sending it a couple hundred > requests to make sure all the pages are compiled. > > before the test starts, use OptimizeIt to garbage > collect. Once that is done, I start the test and > look at the number of threads and size of the heap. > If there's a memory leak, either the thread count > will increase, or the heap will grow rapidly. Once I > see either one, I then switch to the call graph to > get a better picture of which methods are getting > called. Usually, that is enough to point towards a > culprit. > > repeat, and rinse as many times as needed until > you've squashed all bugs and leaks. > > peter lin > > > > > Matt Woodings <[EMAIL PROTECTED]> wrote: > I just read your post this morning (I am lurking > today as I have a few > issues of my own to clear up :-) ) and I think that > is some really good > advice you gave. I do have a question though. > > Once you have noticed you have a memory leak, how > do you go about locating > it? > > Matt > > > --------------------------------- > Do you Yahoo!? > Yahoo! Tax Center - File online by April 15th > > > > <FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE> > ------------------------------------------------------- > QAS Ltd. > Developers of QuickAddress Software > <a href="http://www.qas.com";>www.qas.com</a> > Registered in England: No 2582055 > Registered in Australia: No 082 851 474 > ------------------------------------------------------- > </FONT> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
