Tom Schneider wrote:
David, See https://issues.apache.org/struts/browse/WW-1661 andhttp://wiki.opensymphony.com/display/WW/Performance+Tuning (particularly thefreemarker 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?
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.
Thanks for the help! David
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 againso > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
