tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Casey Lucas" <>
Subject RE: tag handler pooling ideas
Date Thu, 08 Mar 2001 04:16:38 GMT

Thanks for the comments.

> Just a quick note - my experience so far with server-side performance is
> that it doesn't matter how many objects you create, as long as you do it
> only once ( and not for each request ). 

Right.  I was planning on using a web-application-wide collection of pools.

> I don't think doing any reuse inside a page ( i.e. same tag instance 
> beeing reused during a request ) is worth the effort at this stage -
> you'll get most of the benefit and improvements by just using a pool and 
> reusing the tags from request to request - if possible.
> Later you can do more advanced things.

True.  I didn't plan on tackling that one yet.  So, each time a new 
handler is needed in a page, it will be retrieved from its pool.

> Another note - it would be nice if the pool interface is not very
> hardcoded in the implementation. 

Do you mean using interfaces, etc?  If so, I agree.

> Most of the time there is a sync() that
> is hard to avoid in pools, and you get a good improvement by using
> thread data ( in a form or another ). This is a bit hard because the
> same page may be accessed in multiple threads - so you'll have to keep tag
> instances duplicated per thread - but there are solutions to control it 
> without affecting the response time, and most of the times few pages get
> most of the hits - so it's not like all the tags from all the pages will
> be cached at all times.

Well I can do a pool per thread, but my assumption is that there could possibly
be a lot of tag handlers sitting around.  Should this be a concern?  Also,
I don't know the exact thread pooling model that Tomcat uses, but if
it creates and destroys worker thread, that will hurt the pool-per-thread

By doing a web application wide collection of pools, there will be a
synchronized pop (or similar) per handler retrieval and a synchronized
push (or similar) per handler return to the pool.  The synchronization
will occur for handlers that are in the same pool across pages.  Do you think
this might be a problem?

I was thinking of a simple approach to the size of the pools: make sure
that a handler is always available.  This means that the size of each
pool will grow to the max number of concurrent handlers used.
This case is not any worse than the current case (newing one each time).



View raw message