Rickard,
Can you please send in some complete examples? Also, did you run the
tests with and without tag pooling enabled on the same version of
tomcat? (By adding removing TagPoolManagerInterceptor.)
My experience has been that if the jsp uses many tags, then pooling is
a big performance gain. See comments below.
Rickard Öberg wrote:
>
> Hi!
>
> Ok, so now I've tested the Jasper performance with the 3.3 tag pooling
> fix. The test was performed with a medium complexity page using lots of
> iterative custom tags in a hierarchical fashion (i.e. tags within tags).
>
> Results:
> The page ran slower, and above all the response time varied greatly
> (between 250ms and 460ms, whereas without tag pooling we got between
> 230ms and 340ms).
>
> Looking at the generated code, I'm not particularly surprised: it uses
> (it seems) a real shared tag pool, so using tags will execute code that
> needs
> to be synchronized.
Yes, everytime you obtain a tag, there is a synch that occurs for the
pool that exists for each uniquely named tag and specific set of attributes.
There is actually a set of named pools per application context.
>
> This is a bad design. Basically, any gains you get from reusing tags are
> lost due to the overhead and general performance decrease you get by
> using hashtables+"synchronized".
>
Hash lookup is done once per jsp page - when the jsp page is first run.
After that, it's basically a synchronized push / pop pair on all subsequent
runs of the page. In the future we can even get rid of the synch by using
thread local storage... one step at a time though. :)
> I've looked at pages generated by other more efficient JSP compilers
> (e.g. Resin), and they generally use another approach:
> Only reuse a tag within a particular page, and don't use a synchronized
> pool to do it. Just pass the instance around within the generated code.
> What is important is not primarily the global optimization gained by
> using pools, but the local optimization gained by not creating tags for
> each iteration in a iterative custom tag.
>
Yes reusing a tag handler within a single page will be more efficient
(for that particular page) but I would guess that once we change to pool
per thread there's no way newing the tags at each use will be faster
(at least for a busy site with lots of tags.)
> This is waaaay more efficient, and also avoids the suboptimization of
> trying to reuse objects using Java code, something which is more
> efficiently
> handled by modern JVMs' memory management (i.e. creating objects using
> "new" is
> pretty snappy compared with Java-coded pools).
>
I disagree. I've found that object reuse can be a good performance
optimization.
> So, please remove the tag pooling, and do it right. If you don't believe
> me, do some benchmarking or something.
>
I have done benchmarking and pooling enabled always wins. :) Maybe you
can send some examples so that we can try and track down the problems.
Thanks for taking a look at tag pooling. I look forward to refining the
implementation.
-casey
