tag handler pooling ideas

[Casey Lucas <cl...@armassolutions.com>]

I am planning on implementing tag handler pooling and would like
to throw out a few ideas for feedback:

assumptions:
- Tag handlers can only be reused if the same set of attributes
are used for the tag.

- Tag.relese is called only once -- at some point before the
handler is garbage collected.


basic idea:
My general idea was to have a collection of named pools.  Jasper
could then render code to use the named pool to obtain handler
instances instead of newing them each time.


more info:
Each tag handler pool would have a name that would include
the tag's short name and the set of attributes that were used
on the tag.  This would give us the correct reuse level.  So
for the following tags there would be two named pools (after
taking into account attributes):

<x:tag1 attr1="a" attr2="b"/>
<x:tag1 attr1="xyz" attr2="123"/>
<x:tag1 attr1="a"/>

To eliminate the need to lookup the pool by name each time a
tag was needed, pool references could be rendered and initialized
(looked up) when the jsp is initialized.  Inside the main jsp
method (_jspService), the pool references would be used directly.

When the pools are removed (shutdown, reload, etc.) Tag.release
will be called for each of the handlers.  I assume that pools need
to be per web application, but haven't given it a lot of thought.


Any comments / suggestions?

-Casey

RE: tag handler pooling ideas

[Casey Lucas <cl...@armassolutions.com>]

> -----Original Message-----
> From: hans@servlets.net [mailto:hans@servlets.net]On Behalf Of Hans
> Bergsten
> Sent: Wednesday, March 07, 2001 9:06 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: tag handler pooling ideas
> 
> 
> Casey Lucas wrote:
> > 
> > I am planning on implementing tag handler pooling and would like
> > to throw out a few ideas for feedback:
> > 
> > assumptions:
> > - Tag handlers can only be reused if the same set of attributes
> > are used for the tag.
> > 
> > - Tag.relese is called only once -- at some point before the
> > handler is garbage collected.
> 
> I believe you must add one more restriction on reuse: you can only
> reuse tag handlers that are on the same nesting level. For instance,
> this case requires two tag handler instances even though they have
> the same set of attributes:
> 
>   <x:tag1 attr1="a" attr2="b">
>     <x:tag1 attr1="xyz" attr2="123"/>
>   </x:tag1>
> 

True.  This was an obvious one -- I just didn't mention it.

> > basic idea:
> > My general idea was to have a collection of named pools.  Jasper
> > could then render code to use the named pool to obtain handler
> > instances instead of newing them each time.
> > 
> > more info:
> > Each tag handler pool would have a name that would include
> > the tag's short name and the set of attributes that were used
> > on the tag.  
> 
> If by "short name", you mean something that identifies both the
> tag library and the tag, I'm with you. The prefix is not enough.
> The prefix is assigned per page, and you can actually use different 
> prefixes for the same library in different pages, so you need 
> another unique name for the tag library as such. The same problem
> exists with the taglib uri attribute value. Maybe you can use the 
> context-relative path to the TLD; no matter how the TLD is identified 
> by the taglib directive's uri attribute, it must always be resolved 
> to a path to the TLD, and that must be unique within one app.
> 

Right.  I wasn't planning on using the prefix.  The taglib needs
to be included, but I hadn't given the exact manner much thought.  The
TLD path sounds like a good idea.

> > This would give us the correct reuse level.  So
> > for the following tags there would be two named pools (after
> > taking into account attributes):
> > 
> > <x:tag1 attr1="a" attr2="b"/>
> > <x:tag1 attr1="xyz" attr2="123"/>
> > <x:tag1 attr1="a"/>
> > 
> > To eliminate the need to lookup the pool by name each time a
> > tag was needed, pool references could be rendered and initialized
> > (looked up) when the jsp is initialized.  Inside the main jsp
> > method (_jspService), the pool references would be used directly.
> 
> I'm not sure I follow.
> 

Because there will be a collection (HashMap) of pools (Stacks), I don't
want to lookup the correct pool for a handler every time a handler needs
to be used.  The overhead of string hash + lookup can be eliminated by
declaring pool instance variables in the rendered jsp.  Upon jsp
initialization, the pools could be looked up.  Subsequently the pool
references  could be used to get handlers when needed.  What it boils
down to is a Stack pop (synchronized for this one pool) instead of a
HashMap lookup (synchronized across all tag pools) followed by the pop.

Hopefully that made sense.

-casey

Re: tag handler pooling ideas

[Hans Bergsten <ha...@gefionsoftware.com>]

Casey Lucas wrote:
> 
> I am planning on implementing tag handler pooling and would like
> to throw out a few ideas for feedback:
> 
> assumptions:
> - Tag handlers can only be reused if the same set of attributes
> are used for the tag.
> 
> - Tag.relese is called only once -- at some point before the
> handler is garbage collected.

I believe you must add one more restriction on reuse: you can only
reuse tag handlers that are on the same nesting level. For instance,
this case requires two tag handler instances even though they have
the same set of attributes:

  <x:tag1 attr1="a" attr2="b">
    <x:tag1 attr1="xyz" attr2="123"/>
  </x:tag1>

> basic idea:
> My general idea was to have a collection of named pools.  Jasper
> could then render code to use the named pool to obtain handler
> instances instead of newing them each time.
> 
> more info:
> Each tag handler pool would have a name that would include
> the tag's short name and the set of attributes that were used
> on the tag.  

If by "short name", you mean something that identifies both the
tag library and the tag, I'm with you. The prefix is not enough.
The prefix is assigned per page, and you can actually use different 
prefixes for the same library in different pages, so you need 
another unique name for the tag library as such. The same problem
exists with the taglib uri attribute value. Maybe you can use the 
context-relative path to the TLD; no matter how the TLD is identified 
by the taglib directive's uri attribute, it must always be resolved 
to a path to the TLD, and that must be unique within one app.

> This would give us the correct reuse level.  So
> for the following tags there would be two named pools (after
> taking into account attributes):
> 
> <x:tag1 attr1="a" attr2="b"/>
> <x:tag1 attr1="xyz" attr2="123"/>
> <x:tag1 attr1="a"/>
> 
> To eliminate the need to lookup the pool by name each time a
> tag was needed, pool references could be rendered and initialized
> (looked up) when the jsp is initialized.  Inside the main jsp
> method (_jspService), the pool references would be used directly.

I'm not sure I follow.

> When the pools are removed (shutdown, reload, etc.) Tag.release
> will be called for each of the handlers.  I assume that pools need
> to be per web application, but haven't given it a lot of thought.

Right.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

RE: tag handler pooling ideas

[cm...@yahoo.com]

On Wed, 7 Mar 2001, Casey Lucas wrote:
> 
> 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
> model.

It doesn't matter what tomcat uses - this should work on other containers
and models as well ( most decent containers are reusing the threads, 
if they don't probably the performance is bad anyway, or they have 
special needs - like small footprint ). 

It's important to just keep in mind that maybe later it should be possible
to "tune" this and use some other mechanisms ( in adition or instead of
the pool ). 

You probaly don't have to do anything right now - pool is a good start.


> 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?

One collection per webapplication sounds good. Synchronization is not a
big problem right now ( after you 2x the performance it'll be a bit more 
visible ). Keep in mind that a GC is also synchronizing, and object
allocation does a sync() too ( most of the time ).


Costin

RE: tag handler pooling ideas

[Casey Lucas <cl...@armassolutions.com>]

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
model.

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).

-casey


 

Re: tag handler pooling ideas

[cm...@yahoo.com]

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 ). 

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.

Another note - it would be nice if the pool interface is not very
hardcoded in the implementation. 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.

Costin



On Wed, 7 Mar 2001, Casey Lucas wrote:

> I am planning on implementing tag handler pooling and would like
> to throw out a few ideas for feedback:
> 
> assumptions:
> - Tag handlers can only be reused if the same set of attributes
> are used for the tag.
> 
> - Tag.relese is called only once -- at some point before the
> handler is garbage collected.
> 
> 
> basic idea:
> My general idea was to have a collection of named pools.  Jasper
> could then render code to use the named pool to obtain handler
> instances instead of newing them each time.
> 
> 
> more info:
> Each tag handler pool would have a name that would include
> the tag's short name and the set of attributes that were used
> on the tag.  This would give us the correct reuse level.  So
> for the following tags there would be two named pools (after
> taking into account attributes):
> 
> <x:tag1 attr1="a" attr2="b"/>
> <x:tag1 attr1="xyz" attr2="123"/>
> <x:tag1 attr1="a"/>
> 
> To eliminate the need to lookup the pool by name each time a
> tag was needed, pool references could be rendered and initialized
> (looked up) when the jsp is initialized.  Inside the main jsp
> method (_jspService), the pool references would be used directly.
> 
> When the pools are removed (shutdown, reload, etc.) Tag.release
> will be called for each of the handlers.  I assume that pools need
> to be per web application, but haven't given it a lot of thought.
> 
> 
> Any comments / suggestions?
> 
> -Casey
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>