Thanks - I'm actually looking at p6spy right now and
am going to see if it will help to find out if my
problem is in the statements themselves.

But this would seem strange to me because remember
that each page loads very quickly when there is no
load on the web servers.  It's only when I put some
strain on them that things slow down, but during this
time I'm not seeing any sort of contention on the db
end.  I'm thinking that the problem is actually more
of a bottle neck on the web server attempting to
establish connections to the db, but am unsure how to
find that out for sure.

-marc

--- Martin Gainty <[EMAIL PROTECTED]> wrote:

> I was thinking along the same lines and was
> wondering if the topic of 
> performance tuning would be wandering 'O/T'
> You will need to find a way to turn on execution
> plans and trace logs for 
> your DB vendor's DB Instance or on a per session
> basis
> Dig thru the DB doc to find how to optimise your
> queries specifically to 
> setup a mirror box to ascertain the deltas between
> the old query and the 
> optimized query
> I can help you implementing this with Oracle..but am
> hard pressed for 
> specific details on implementing performance tuning
> with DB2
> 
> Anyone else?
> Viel Gluck!
> Martin-
> 
> ----- Original Message ----- 
> From: "Jess Holle" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <users@tomcat.apache.org>
> Sent: Friday, December 16, 2005 10:29 AM
> Subject: Re: Performance degradation under load
> 
> 
> > Caldarale, Charles R wrote:
> >
> >>This really sounds like you're not using
> connection pooling, but instead
> >>are opening a new connection for each request. 
> How many do you have
> >>configured in the pool?  If it's less than the
> number you see with
> >>netstat, that would be another indication that
> your app is getting its
> >>own connections rather than ones from the pool.
> >>
> >>Is your app closing the connections (and
> statements and result sets)
> >>properly?  This usualy requires putting the close
> statements in finally
> >>blocks, just to make sure that exceptions don't
> cause them to be
> >>skipped.
> >>
> > Additionally, you speak of multiple connections
> because you need to hit 
> > multiple tables.
> >
> > There are cases where such is all but necessary,
> but enough sophistication 
> > with unions, joins, etc, can reduce the number of
> round trips you make to 
> > the database, which can be quite important given
> any communication 
> > latency.
> >
> > --
> > Jess Holle
> >
> >
>
---------------------------------------------------------------------
> > 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]

Reply via email to