David H. DeWolf wrote:
Tom Schneider wrote:
David,
See https://issues.apache.org/struts/browse/WW-1661
and
http://wiki.opensymphony.com/display/WW/Performance+Tuning
(particularly the
freemarker entries)
By just adding the freemarker.properties and copying all the
templates to
the webapp directory we were able to resolve all of our freemarker
performance issues. (or at least get the page render times down to a
point
where they weren't an issue for us)
Unfortunately, I've tried both the props and copying the templates and
am still having the issues. I assume the big prop you're talking
about is template_update_delay. Any others you found useful for
performance?
The big thing for us was moving the freemarker templates to the war,
rather than letting them get loaded via the classpath. It seems that if
you let the templates get loaded via the classpath rather than the
filesystem, then freemarker has no last modified time to check to see if
it needs to reload it, so it reloads and reparses the template every
time. If the template is available via the filesystem, it has a last
modified time to check and then the caching can work as expected. The
template_update_delay is just a setting that controls how long
freemarker will go before it will explicitly reload the template
regardless of the last modified time. Setting this property helped, but
is was only an incremental increase to performance. You must do both to
realize the greatest benefits. (In fact the template_update_delay is
useless if the templates are being loaded from the classpath) Those are
the only 2 tweaks I made to the freemarker stuff to get it to perform well.
We were using the simple theme, so most of our text output uses the
ww:text
tag--we did not have to use %{getText(...)} at all in our JSP's. I'm
not
sure if it's doing the same thing under the hood, but you might want to
experiment with that. I would say, make the freemarker changes, then
see
what kind of times you are getting. We were able to get all our
pages to
render in about 50-150 ms. (about 100-200 ms total page load time)
Originally we were seeing about 150-300+ ms render time for the pages.
(without the caching, the numbers were much more sporadic)
Thanks for the tip. I'm using the xhtml theme and will do some
benchmarking between the two. I've looked further into the method
invocation/getText issue and I think it's real, though I'm wondering
why it hasn't been reported before considering how significant it is.
The 50-150/100-200 ms times are exactly what I'm looking for. I'm
currently seeing 1200-2400 when I have 15-20 form fields using
getText. As soon as I take out the method invocations and use the
optomized OGNL stack, I drop down to 300.
!!!! Yikes, that doesn't seem right at all. :) Unless you're rendering
a lot of UI tags, even the 300 seems high. If OGNL was truly the issue,
it should be relatively easy to generate a junit test that simulates
what is going on in OGNL when you make those getText calls. Once you
have that I don't think it would be too difficult to either use a
profiler or instrutment the code to figure out exactly where in OGNL all
that time is being spent. There might be a simple fix for this issue.
(Or at least we could try some of the performance patched code)
The other thing to check is to make sure devmode is off. With devmode
on, the resource bundles will be reloaded quite offend vs. not being
reload at all with devmode off. That could definitely be a culprit if
the getText calls are taking so long.
That's all I can think of at the moment. Let us know if you make any
progress--I've been in OGNL enough over the last month to be pretty
familiar with it. (There was a race condition that I discovered that
was a pain to track down--we finally reproduced this under JBoss so I
hope we get an official OGNL release with this patched soon)
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
