tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prashant Rao" <p...@firstrain.com>
Subject StandardManager
Date Sat, 13 Oct 2001 20:35:58 GMT
Hi 
	I am currently working on a product using tomcat3.2 as a servlet
engine.  The product i am working on is computationally intensive.  The
tests conducted for the product included a stress test using a web
stress testing tool that continuously sent requests to the server as
long as the server could handle them (Microsoft WAS tool ). There were
about three-to-five threads for the different tests constantly sending
requests to the server.  Each new request creates a new session since
cookies were turned off.  The session-time out  was set at 1 minute in
the tomcat web.xml as well as the web.xml file in the application (under
webapps/appname/WEB-INF)

	The average statistics showed that the number of sessions on the
server grew continuously for the duration of the test.  Though the
session-time out was set for one minute.  But as soon as the stress
thest was stopped the house keeping thread (StandardManager) started to
drop all the sessions.  In fact the number of sessions created are so
large (go into thousands)(with the throughput that the product has and a
1 minute time out the number of valid sessions should have been around
400-to-500) that the sessions are serialized and once the stress test
ended the sessions were deserialized and then nuked.  The product
attaches some of the objects to the session by implementing
sessionBinding listener.  Thus if a session is not dropped valuable
resources are held up.  Can some one suggest as to why this his
happening ?

	Also as an understandable outcome (since the sessions are not
dropped some of the objects associated with the session are in the heap)
the java heap size grew considerably.  Ultimately it exceeded the
default java heap size of the OS (MS-2000) and the server stopped with
an out-of-memmory exception.  

Can some one please shed some light on this behavior.  Does the
StandardManager thread run on an low priority ? Is there some way to
bump up the priority of the StandardManager.  Is there some settings not
being used properly (The timeout seems to be o.k. as all the sessions
begin to get dropped as soon as the stress test ends.)

Any suggestions are welcome .

P.S. The tests had a continuous load pattern. Does usage of tomcat
mandate a bursting load pattern where the Standard manager get the time
and resources to clean up?  If the above problem is not a setup problem
how can I make tomcat scale to heavy load servers ?

Regards 
Prashant 

Mime
View raw message