You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "David H. DeWolf" <dd...@apache.org> on 2007/01/26 19:48:04 UTC
Fast ValueStack
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by "David H. DeWolf" <dd...@apache.org>.
Tom Schneider wrote:
>
> 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.
>
Apparently there's an additional property, struts.i18n.reload, that also
will turn that feature on. Even if devmode is off, if set to true, it
will reload each request. After finding that and switching to off, I'm
back down under 200 ms.
#@$%!
The tweaks to the OGNL stack do seem to make a bit of difference, but
more in line with the few ms here or there that you'd expect.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by Tom Schneider <sc...@gmail.com>.
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
Re: Fast ValueStack
Posted by "David H. DeWolf" <dd...@apache.org>.
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?
>
> 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 <dd...@apache.org> 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 <dd...@apache.org> 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: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by Tom Schneider <sc...@gmail.com>.
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 <dd...@apache.org> 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 <dd...@apache.org> 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: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Fast ValueStack
Posted by Tom Schneider <sc...@gmail.com>.
Oops, the numbers aren't quite as bad as I thought. The original
numbers included the cost of compiling the OGNL expression. If you
exclude the OGNL compilation the numbers are:
Using OGNL expression: 15 ms
Explicitly calling getText: 0 ms
I knew that compiling the OGNL expression took a long time, but I didn't
realize it was that long. I still think there is a benefit to updating
the way the UIBean does key lookup. At a minimum it will make the Text
and other UIBeans more consistent and there is a slight performance benefit.
I'm glad you resolved your issue. I knew about the other property, but
I normally don't set that one explicitly--so I didn't think to mention
it. :) That definitely explains the huge numbers.
Tom
David H. DeWolf wrote:
> Nice, that seems in line with what I'm seeing as well now. I still
> think this is worth improving, as those 5ms can add up on larger forms.
>
> Tom Schneider wrote:
>> Well, I guess I was feeling more ambitious than I thought.
>>
>> I wrote a simple junit test (below) that tests the 2 techniques for
>> retrieving I18N text. My numbers for 100 iterations were:
>> Using OGNL expression: 476 ms
>> Explicitly calling getText: 0 ms
>>
>> Yikes!!! There is quite a difference between the two. The OGNL
>> version takes 5 ms/request compared to almost nothing for the
>> explicit call. It looks like it would be very beneficial to
>> reimplement the UIBean key lookup code based on the Text
>> component-style of text lookup.
>
> Agreed. I've created:
>
> https://issues.apache.org/struts/browse/WW-1681
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by "David H. DeWolf" <dd...@apache.org>.
Nice, that seems in line with what I'm seeing as well now. I still
think this is worth improving, as those 5ms can add up on larger forms.
Tom Schneider wrote:
> Well, I guess I was feeling more ambitious than I thought.
>
> I wrote a simple junit test (below) that tests the 2 techniques for
> retrieving I18N text. My numbers for 100 iterations were:
> Using OGNL expression: 476 ms
> Explicitly calling getText: 0 ms
>
> Yikes!!! There is quite a difference between the two. The OGNL version
> takes 5 ms/request compared to almost nothing for the explicit call. It
> looks like it would be very beneficial to reimplement the UIBean key
> lookup code based on the Text component-style of text lookup.
Agreed. I've created:
https://issues.apache.org/struts/browse/WW-1681
I think
> the key attribute is a much cleaner way of specifying label text anyway
> so it's good to give users an incentive to use it. :)
>
> Tom
>
> /************ start source code **************/
> package example;
>
> import java.util.Iterator;
>
> import junit.framework.TestCase;
>
> import com.opensymphony.xwork2.ActionSupport;
> import com.opensymphony.xwork2.TextProvider;
> import com.opensymphony.xwork2.util.OgnlValueStack;
>
> public class TestOgnl extends TestCase {
>
> public void testOgnl() {
> TestAction action = new TestAction();
> OgnlValueStack stack = new OgnlValueStack();
> stack.push(action);
> String value = null;
> long start = System.currentTimeMillis();
> for(int i = 0; i < 100; i++) {
> value = stack.findString("getText('key')");
> }
> long end = System.currentTimeMillis();
> assertEquals("value", value);
> System.out.println((end - start));
> start = System.currentTimeMillis();
> for(int i = 0; i < 100; i++) {
> value = findString(stack, "key");
> }
> end = System.currentTimeMillis();
> System.out.println((end - start));
> assertEquals("value", value);
> }
>
> protected String findString(OgnlValueStack stack, String key) {
> for(Iterator iterator = stack.getRoot().iterator(); iterator
> .hasNext();) {
> Object o = iterator.next();
>
> if(o instanceof TextProvider) {
> TextProvider tp = (TextProvider) o;
> return tp.getText(key);
> }
> }
> return null;
> }
> }
>
> class TestAction extends ActionSupport {
>
> @Override
> public String getText(String arg0) {
> if("key".equals(arg0)) {
> return "value";
> }
> return null;
> }
>
> }
> /************ end source code **************/
>
> Ted Husted wrote:
>>
>> The tags now have a "key" attribute that can be used in place of the
>> getText OGNL expression.
>>
>> I'd be curious to know if
>>
>> <s:textfield key="lastName" />
>>
>> runs faster than
>>
>> <s:textfield label="%getText('lastName')" name="lastName" />
>>
>> If so, I wonder if there other places where we could eliminate common
>> OGNL statements by adding functionality to the tags.
>>
>> -Ted.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by Tom Schneider <sc...@gmail.com>.
Well, I guess I was feeling more ambitious than I thought.
I wrote a simple junit test (below) that tests the 2 techniques for
retrieving I18N text. My numbers for 100 iterations were:
Using OGNL expression: 476 ms
Explicitly calling getText: 0 ms
Yikes!!! There is quite a difference between the two. The OGNL version
takes 5 ms/request compared to almost nothing for the explicit call. It
looks like it would be very beneficial to reimplement the UIBean key
lookup code based on the Text component-style of text lookup. I think
the key attribute is a much cleaner way of specifying label text anyway
so it's good to give users an incentive to use it. :)
Tom
/************ start source code **************/
package example;
import java.util.Iterator;
import junit.framework.TestCase;
import com.opensymphony.xwork2.ActionSupport;
import com.opensymphony.xwork2.TextProvider;
import com.opensymphony.xwork2.util.OgnlValueStack;
public class TestOgnl extends TestCase {
public void testOgnl() {
TestAction action = new TestAction();
OgnlValueStack stack = new OgnlValueStack();
stack.push(action);
String value = null;
long start = System.currentTimeMillis();
for(int i = 0; i < 100; i++) {
value = stack.findString("getText('key')");
}
long end = System.currentTimeMillis();
assertEquals("value", value);
System.out.println((end - start));
start = System.currentTimeMillis();
for(int i = 0; i < 100; i++) {
value = findString(stack, "key");
}
end = System.currentTimeMillis();
System.out.println((end - start));
assertEquals("value", value);
}
protected String findString(OgnlValueStack stack, String key) {
for(Iterator iterator = stack.getRoot().iterator(); iterator
.hasNext();) {
Object o = iterator.next();
if(o instanceof TextProvider) {
TextProvider tp = (TextProvider) o;
return tp.getText(key);
}
}
return null;
}
}
class TestAction extends ActionSupport {
@Override
public String getText(String arg0) {
if("key".equals(arg0)) {
return "value";
}
return null;
}
}
/************ end source code **************/
Ted Husted wrote:
>
> The tags now have a "key" attribute that can be used in place of the
> getText OGNL expression.
>
> I'd be curious to know if
>
> <s:textfield key="lastName" />
>
> runs faster than
>
> <s:textfield label="%getText('lastName')" name="lastName" />
>
> If so, I wonder if there other places where we could eliminate common
> OGNL statements by adding functionality to the tags.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by Tom Schneider <sc...@gmail.com>.
From UIBean.java:
if (this.key != null) {
if(this.name == null) {
this.name = key;
}
if(this.label == null) {
this.label = "%{getText('"+ key +"')}";
}
}
Looks like it's doing exactly the same thing. :(
Even more interesting, look what's going on in the Text.java UI component:
for (Iterator iterator = getStack().getRoot().iterator();
iterator.hasNext();) {
Object o = iterator.next();
if (o instanceof TextProvider) {
TextProvider tp = (TextProvider) o;
msg = tp.getText(actualName, defaultMessage, values, stack);
break;
}
}
No wonder I didn't see any performance issues here and David did--this
definitely looks like it would be faster. :) We should probably adopt
this model of looking up text in the UIBean class when a key is provided
as it might speed things up. I'd love to see some before/after
numbers. This might be a tweak you want to apply locally and see if
there's a performance gain. (I'll post some if I find some time this
weekend)
Tom
Ted Husted wrote:
> On 1/26/07, David H. DeWolf <dd...@apache.org> wrote:
>> 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.
>
> The tags now have a "key" attribute that can be used in place of the
> getText OGNL expression.
>
> I'd be curious to know if
>
> <s:textfield key="lastName" />
>
> runs faster than
>
> <s:textfield label="%getText('lastName')" name="lastName" />
>
> If so, I wonder if there other places where we could eliminate common
> OGNL statements by adding functionality to the tags.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by Ted Husted <hu...@apache.org>.
On 1/26/07, David H. DeWolf <dd...@apache.org> wrote:
> 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.
The tags now have a "key" attribute that can be used in place of the
getText OGNL expression.
I'd be curious to know if
<s:textfield key="lastName" />
runs faster than
<s:textfield label="%getText('lastName')" name="lastName" />
If so, I wonder if there other places where we could eliminate common
OGNL statements by adding functionality to the tags.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by Don Brown <do...@gmail.com>.
This might be applicable: http://crazybob.org/2007/01/fast-reflection.html
Don
On 1/26/07, David H. DeWolf <dd...@apache.org> 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 <dd...@apache.org> 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: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by "David H. DeWolf" <dd...@apache.org>.
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 <dd...@apache.org> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fast ValueStack
Posted by Tom Schneider <sc...@gmail.com>.
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 <dd...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>