Agreed. We are doing quite a bit of database access per app call though - we run JD Edwards OneWorld on the backend and our web apps are using those tables entirely. JDE wasn't exactly created on the premise of efficiency - it's made entirely for flexability, which (in my mind) is the exact opposite of efficiency. That means that there are a real lot of tables and that each call to the web app will cause many table accesses at once.
When I kill all db connections and start with a clean slate, I can hit the web app one time (just log in) and see 5 new connections start up. Well guess what? In order to build a user session I need to read from 5 db tables. When I move to another screen, I also see the same number of connections open up as there are tables to be read from that app. I do believe that I'm opening one connection per table, doing a single read and then abandoning the connection. But I was under the impression that Tomcat's pool manager would calm this effect a bit, though it doesn't appear to be helping at all. You can see that if you have a really heavy database and that if you are opening one connection per table per app read (per user) and have 30 or 40 users pounding away simutaneously, you would end up with a whole lot of open connections really quick. But my servers have more than enough cpu capacity to deal with cleaning up the open connections and my iSeries is a monster - I couldn't make the cpu's even blink if I tried (and it has 6 active gygabit ports, so I'm not worried about tying up ethernet). So, while I'm sure this isn't ideal chat behaviour between two machines, I don't really know that it is what is causing my performance issue. I think I'll need to solve this particular problem, and perhaps when I do I'll have licked my degradation issue as well, but I'm not really sure where to begin with either at the moment. -marc --- 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] > > > > > __________________________________________________ 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]
