While you are running how many database connections does your database report having open? You might want to use the tomcat manager status app to see how many threads you are using, how many sessions are being created, etc. Lots of sessions can eat up memory as well if they are not being killed off quickly enough. If you have lots of threads coming in, make sure to set your maxThreads and associated parameters to handle the load. Also check your queue depth, once the queue fills up no more requests are going to come thru.
Is your database reporting any core dumps, or alerts, or deadlocks? On 12/15/05 11:01 PM, "Peter Lin" <[EMAIL PROTECTED]> wrote: > under normal conditions, a single webserver shouldn't have several thousand > DB connections. that seems a bit odd to me. > > peter lin > > > On 12/15/05, Martin Gainty <[EMAIL PROTECTED]> wrote: >> >> Marc- >> what types of Coyote Point Equalizers are you using? >> What does the Doc say about configuring the CPE for 30-40 consecutive >> users? >> Martin- >> ----- Original Message ----- >> From: "Marc Richards" <[EMAIL PROTECTED]> >> To: "Tomcat Users List" <users@tomcat.apache.org> >> Sent: Thursday, December 15, 2005 7:57 PM >> Subject: Performance degradation under load >> >> >>> I have a performance issue that I'm having trouble >>> with - perhaps somebody has seen this sort of thing >>> before and can help me out. >>> >>> Problem: >>> Under no load my page responses average about 1.2 >>> seconds (according to jmeter tests), which is pretty >>> good considering the heavy jdbc useage of my >>> applications. However, once I begin to ramp up the >>> load to 30 or 40 consecutive users the performance >>> quickly degrades down to about 4 seconds average >>> response time. While this takes place, the machines >>> are only showing about 5% cpu utilization and have >>> 3.5gb of memory freely available. Network resources >>> also appear to be free. So I definitely don't have a >>> hardware issue, especially considering that there are >>> two balanced machines and neither are showing more >>> than 5% busy. I seem to have a bottle neck somewhere >>> in the system, but am unsure how to track it down. >>> >>> Setup background: >>> This is a new setup that's not in production yet. I'm >>> running Apache 2.05x and Tomcat 5.5x using mod_jk. >>> Apache and Tomcat reside together on both machines >>> (Win 2003), so there should be virtually no latency >>> between them. The machines are balanced on the front >>> end by Coyote Point Equalizers. >>> >>> Tomcat is handling connection pooling to our iSeries >>> database server (db2, jdbc), but I'm not sure it's >>> working correctly because when I do netstat I see >>> several thousand db connections sitting at TIME_WAIT >>> (presumably abandoned and waiting to be cleaned up by >>> the pool manager). This could be one of my problems, >>> but I don't think it's the whole problem and I don't >>> know how to verify. The call to the pool manager is >>> actually coming from the Spring Framework, which >>> possibly has a bug in it, but I suspect instead that >>> Tomcat is not returning the connections to the pool >>> (unless I'm interpreting the existance of so many >>> connections entirely wrong to begin with). >>> I'm also using Tomcat to persist my sessions >>> occasionally (every 2 minutes) to the same iSeries. >>> >>> I see several possible bottle neck points; the http >>> forward from the load balancer to the server machine >>> (very unlikely), the tcp communication between Tomcat >>> and Apache (maybe), the jdbc connections to the >>> iSeries (this is my top suspect at the moment) or some >>> sort of db collusion occuring on the sessions >>> persistance table. >>> >>> The big question: Anybody know a slick way to find >>> out what it is? >>> >>> Thanks, >>> >>> -marc >>> >>> >>> >>> >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.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]
