[EMAIL PROTECTED] wrote:
> > > We know the pool is synchronized and that may create problems under heavy
> > > load, and we know how to fix this ( by using a per/thread pool without
> > > synchronization ).
> >
> > That is one solution, but what do you do with the pool after page
> > request?
>
> I'm not sure I understand. Each thread has a number of associated objects
> that are recycled and reused - a Request object will "stick" with a
> thread.
>
> Same can be done for the tag pools - except that this may use a lot of
> memory ( but less than allocating/freeing ). It is possible to use a
> middle ground, or tune this - but for maximum performance you can have a
> local pool in each Request.
What I was considering is this: a pool is a managed resource, since it
can shrink and grow. After a page request, you will want to reuse the
pool and its contents, but you can't stick the contents into a global
pool, because at next request how are you to know how many instances of
a tag to put in the request-associated pool. I.e., thread-associated
pools perform local optimizations per request/page, but for pools to be
of any use they need to do global optimizations, i.e. pool the tags in a
global pool. Otherwise you'll have lots of pools of tags and no way to
manage them globally.
Example:
Page request. No pools created yet.
Page uses tag "foo" 10 times. Pool, associated with request/thread,
created containing one "foo" tag instance.
Concurrent page request with the above.
Page uses tag "foo" 5 times. Another pool, associated with
request/thread, created containing one "foo" tag instance.
Both requests end: what to do with the pools?
1 Keep separate, each containing one instance
2 Merge so that there is only one pool for "foo" tags
If 1, then there's no way to do proper global optimizations, i.e. say
"don't create more than x tag instances".
If 2, then at next request, what should the page associated "foo" pool
contain? 1 tag instance, 2 tag instances..? The only way to really know
is for the page to do its thing, and pull the tags from the global pool.
And then you're in "synch" land again.
Do you understand now? I realize the above is a bit fuzzy...
> > I hope that Costin will be able to reproduce what I found.
>
> I hope not :-)
>
> Again - thanks for doing the tests and checking the code, and hope to see
> more contributions and maybe few patches :-)
Jasper performance is a high priority thing for us (nr 1. on our "system
performance fixing" list actually), so if possible, absolutely. I can't
say I've delved that far into Jasper yet though. It was a bit hard to
read.
> IMHO the right answer is "depends". And it depends on the actual use case,
> on how many objects are created and where the synchronization occurs. For
> tomcat, where we expect hundred of concurent requests and each would
> create almost a hundred object ( that was the case in 3.0 ) - I doubt any
> VM could make a difference.
Have you then considered the middle way I proposed, where each page
creates the tags it needs, but only once. In my experience, the
performance kills is in iterative and recursive use of tags, e.g.:
<iterate>
<foo/>
</iterate>
which will create one "foo" tag per iteration in 3.2. *That's* the
biggest problem IMHO. Creating the "iterate" and "foo" tag once for that
page is not, considering that the overhead of managing pools of these
tag instances is more resource draining, and hard to do properly on a
global scale.
I might be wrong though 8-)
Nah. >:-)
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
