Rickard Öberg wrote:
>
> [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 just had an idea (dangerous things) regarding tag pooling optimizations.
When Jasper translates a page it should be able to generate information
about which tag handler classes it needs, and for each tag handler, the
profile of the attribute/value pairs. At runtime Jasper could make one call
to a tag pooling synchronized method to get all available instances of the tag handlers
it needs. Any tag handlers/attribute profiles it couldn't obtain, it would have
to create. Then it would manage its own local tag pool during the execution
of the request. On termination of the request, after the page has been committed
to the remote client, it would make one call to a tag pooling synchronized
method to recycle/add the tag handlers it used. So there would only be 2
synchronized methods per page for implementing tag pooling regardless of
how many tags are used. And you have the benifits of minimizing JVM memory
usage by sharing a global JVM tag pool.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
