tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Sweeney" <>
Subject RE: Performance issue
Date Thu, 07 Oct 2004 21:39:06 GMT
All the posts so far are right - you'll need to profile the app ;-)

A few "tuning" thoughts as you zero in on the app issues: 

Check your logs.  Are you getting "connection refused" errors at peak when the pages take
so long to load?  Modify your connector in your server.xml.  You can up the maxProcessors="254"
before needing to grab the source.  If there is a need to up the wait queue you can up acceptCount="300".
 Also lessen the cycles for DNS lookups by enableLookups="false".

Are you starved for DB connections?  Add more in your [app_context].xml (20 is default I think)

Is the compiler and execution servlet in developer mode?  Is Tomcat looking for changes in
the JSPs at every access?  Look in web.xml and make

Up your checkinterval or set 'reloading' to false as well.

You said "I have 128M initial memory, and 2GB max memory for JVM."  In production consider
giving Tomcat all the memory at initial startup that you intend to give it at max.  We saw
evidence of memory fragmentation that was a performance hit in our testing.  But again, you
need to profile your app.  Are you swapping?  

You said "we're using a wrapper to restart it after it crashes."  Are you precompiling the
app, or compiling the pages on access?  If not precompiling, you have beefy iron but enough
restarts and that is a lot of cycles at peak.

Good Luck - 


-----Original Message-----
From: QM []
Sent: Thursday, October 07, 2004 7:46 AM
To: Tomcat Users List
Subject: Re: Performance issue

On Thu, Oct 07, 2004 at 11:40:50AM +0800, Faisal Abdullah wrote:
: I think its probably its how the app manages connection, and probably GC?
: DBCP and Cayote HTTP1/1 isn't configured by the way. Would these help?
: If I configure DBCP, would it effect the code?

DBCP may affect the overall app performance: it keeps a set of open
database connections, instead of initiating a new connection each time
someone calls the database.  The creation/teardown of a network
connection can be expensive.

Right now it seems you're guessing at the cause.  (You're likely
correct, but still guessing.)  Analyze the app with a profiler to
determine exactly what's going on.  A profiler will show you what method
calls are taking the most time, what's in the heap, whether GC is the
cause of the performance problem, etc.



software  --
tech news --

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message