[EMAIL PROTECTED] 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.
Sounds like a good plan :-) I'd be happy to help out with commenting on
the code. Code contribution is tricky right now (lots of other
OpenSource projects to manage :-).
> 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 !!! ).
Whoa.. I didn't know that.. that's an important factor to consider then.
> 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.
As long as the synchs are few, and the block itself is short, you should
be ok.
> 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.
That could work.
> 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 ).
The big date for me is 2002-01-01. Before that I need some kind of
"assurance" that it'll improve greatly 'till that time, or we need to
look at alternatives (*shiver*).
So sooner than later, sure, but preferably righter than sooner. Get this
stuff right, and I think you'll get lots of new supporters and keep old
ones ;-)
> 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.
I will start looking at optimizations on my side of things to, for sure.
My code isn't extremely optimized, I know that, but OTOH I've tested the
same code with WebLogic 5.0 (just to test) and it was waaaay faster, so
there's definitely room on the JSP side to improve things.
> 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.
Yup, that seems reasonable.
You mentioned in your private email that there was a lot of
MethodDescriptor's being created. Please look into where these are
coming from. They could be associated with the tag setters. Pool/cache
these and you'll probably see some immediate results.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
