On Wed, 23 May 2001, Rickard Öberg wrote:
> 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.
I'm working on a refactoring of jasper, and "easy to read" is a big
priority. It's moving a bit slower than I expected - now I'm back on
planning stage after hearing so much bad things about using XSLT :-) But I
think there are ways to make ( almost ) everyone happy.
I hope in few weeks ( after JavaOne ) we'll have something that works for
both 1.1 and 1.2 ( the first part of refactoring ), and we can start the
fun part - optimizing it.
> 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.
Yes, in-page reuse is where thread local pools would probably make the
most difference. It's not only about the tag itself, it's also the
ContentBody and few other internal elements that need to be recycled.
( recycling the JspWriterImpl had a very nice effect ).
The main problem is to avoid one synchronized call for each tag (
"new" _is_also_ a synchronized call on most VMs - it synchronizes
the heap !!! ). Tomcat3.3 has one synchronized call to get the worker
thread from the pool - and that doesn't seem to show up in any
performance tests.
We could keep a pool of pools ( probably for each context ). The local
pools can be unsynchronized - so we'll have only one sync per page. Each
context will have a set of pools ( with the size == the largest number of
concurent requests for that context ). And we can of course be agressive
in shrinking the pools that were not used recently.
We can try to do some of this in 3.3 space - or in a branch of 3.3 (
jasper34 is going to take a while, and I have a feeling you need results
fast ).
Regarding your application - I think we know the problem. There are few
things you can do to reduce the memory use, and you could cache and
recycle intermediary objects in each tag instance - you could benefit a
lot from the reuse of the tags.
The memory savings of the thread pooling are not helping your application
yet ( since they are very small compared with the rest ), yet you pay the
synchronization price ( a lot - since you make heavy use of tags ). With
few changes in your app and few changes in the tag pool we could reverse
the situation - but if you disable the pool there's little chance you
could increase the performance above the current level.
Costin
