struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Schneider <schne...@gmail.com>
Subject Re: Fast ValueStack
Date Sat, 27 Jan 2007 01:01:20 GMT
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message