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)
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)
Tom
On 1/26/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:
Well, I hope I'm wrong, and have only done some initial tests so far,
but it seems to me that there are two major issues causing our
slugishness. The first seems to be OGNL and the second seems to be
freemarker templates.
By simply replacing the default value stack with the version Bob posted,
I realized a gain of about 100-200ms per request on some fairly simple
pages. The real kicker is when I remove the method invocations
(%{getText('')}) - this results in a 1100-1200ms/request gain (an
average of about 100ms per method invocation) and drops my total request
time to well under a second.
That's why I'm thinking about looking at method processing.
What did you find to be your culprit? Anything ww/struts related?
David
Tom Schneider wrote:
> Hey David,
> Are you finding the existing ValueStack to be impacting performance? I
> recently wrapped up a week of tweaking our webwork app and I did some
> testing of the OGNL expressions and that was definitely not where our
> performance issues were. If OGNL is an issue for you, I'd be curious to
> know how you are using OGNL and maybe try and figure why it's not
> performing
> well for you. (Based on a conversation with Phil, I confirmed that OGNL
> expressions where being cached at a JVM level in xwork--so most of the
> expressions should be running as compiled expressions) For example, if
you
> could come up with some example code that you can share with us that
> performs poorly with the existing OGNL implementation.
>
> As far as other options, Jesse (from Tapestry) has created some patches
for
> OGNL that should definitely improve the performance. Checkout
> http://forums.opensymphony.com/thread.jspa?threadID=59785&tstart=-1 for
> details. We're working on getting the OGNL project up and running again
so
> at some point these should make it into a future release.
> Tom
>
> On 1/26/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:
>>
>> I'm going to be looking into optimizing the performance of the
>> ValueStack and because of the recent conversations regarding OGNL and
>> other options, I anticipate that others may have some ideas.
>>
>> I've ripped off the custom stack that Bob posted to the list a couple
of
>> a weeks ago, and have realized significant gains using it, however,
>> because it only optimizes simple properties, I still think there's a
lot
>> of room for improvement. Specifically, method invocations are very
>> expensive and happen to be used often in processing the components -
>> especially if you use i18n features (getText()), etc...
>>
>> I think I'm going to start by looking at MVEL, what other ideas do
>> people have?
>>
>>
>> David
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
