You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dale Newfield <Da...@Newfield.org> on 2008/06/25 20:31:26 UTC
Re: [struts] Slow performance with Struts2
yorlick kilroy wrote:
> Still... the "problem" seems to be the OGNL implementation in struts2.
I'm guessing here, but maybe your issues are related to:
http://jira.opensymphony.com/browse/OGNL-141
Which has been pushed off in Xwork to 2.5:
http://jira.opensymphony.com/browse/XW-631
And which has been pushed off in Struts2 until at least 2.1.3:
https://issues.apache.org/struts/browse/WW-2128
You're welcome to update the version of ognl you're using in your own
app (but remember to add javassist if so).
> <s:iterate ... >
> <s:property value="#object.a.b.c.name"/>
> <s:property value="#object.a.b.c.phone"/>
> </s:iterate>
Theoretically this translates to a straight lookup for #object, then
getA().getB().getC().getName()...
If A, B, and C are just accessors, it should be fast. If they do much
work to determine what to return, you're doing that work 2*N times
(where N is the number of times through the loop) instead of just
once...why would you put a long lookup like that in an iterator if it
doesn't change with each iteration?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] Slow performance with Struts2
Posted by Dale Newfield <Da...@Newfield.org>.
yorlick kilroy wrote:
> firstly ognl 2.6.11 was faster than 2.7.2 with or without javassist
> everytime, no matter how often I executed the test.
Thank you for doing this test!
I guess I'll be following your lead reverting back to 2.6.11 myself.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] Slow performance with Struts2
Posted by yorlick kilroy <wg...@gmail.com>.
Ok, I started a new test with ognl 2.6.11 vs ognl 2.7.2 vs ognl 2.7.2 +
javassist
Request-response time was stopped with Yslow firefox plugin for firefox 3
firstly ognl 2.6.11 was faster than 2.7.2 with or without javassist
everytime, no matter how often I executed the test.
I couldn't notice any difference in performance between 2.7.2 and 2.7.2 +
javassist.
Anyway, I reverted back to 2.6.11. (Still disappointed with how slow struts2
is compared to struts1 despite haven taken all the performance tuning
measures listed on the apache site)
On Thu, Jul 3, 2008 at 2:34 AM, Dale Newfield <Da...@newfield.org> wrote:
> yorlick kilroy wrote:
>
>> I'm sorry but I only just read about javassist now, as I had no idea what
>> it
>> is nor does. How do I include it? do I just drop it in my lib folder like
>> I
>> do with other Struts plugins? How do I use it? and what exactly does it
>> do?
>>
>
> Yes, just drop the .jar into your WEB-INF/lib directory.
> http://www.csg.is.titech.ac.jp/~chiba/javassist/<http://www.csg.is.titech.ac.jp/%7Echiba/javassist/>
>
> I believe it's used by ognl, if present. "Javassist is a Java library
> providing means to manipulate the Java bytecode of an application. In this
> sense Javassist provides the support for structural reflection, i.e. the
> ability to change the implementation of a class at runtime." Basically if I
> understand it correctly, ognl2.7 can do some amount of "expression
> compilation" in such a way that less work is needed when those same (sub?)
> expressions are next evaluated.
>
> I believe most of the benefits won't be realized until we jump through a
> number of hoops in our use of ognl that we've yet to implement in
> xwork2/struts2, but if this (possibly premature) "upgrade" actively slows
> down ognl evaluation, I'd like to know. (Since I swapped in these more
> recent ognl version in the project I'm currently developing, I'd really like
> to know if that was a step backwards.)
>
> -Dale
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: [struts] Slow performance with Struts2
Posted by Dale Newfield <Da...@Newfield.org>.
yorlick kilroy wrote:
> I'm sorry but I only just read about javassist now, as I had no idea what it
> is nor does. How do I include it? do I just drop it in my lib folder like I
> do with other Struts plugins? How do I use it? and what exactly does it do?
Yes, just drop the .jar into your WEB-INF/lib directory.
http://www.csg.is.titech.ac.jp/~chiba/javassist/
I believe it's used by ognl, if present. "Javassist is a Java library
providing means to manipulate the Java bytecode of an application. In
this sense Javassist provides the support for structural reflection,
i.e. the ability to change the implementation of a class at runtime."
Basically if I understand it correctly, ognl2.7 can do some amount of
"expression compilation" in such a way that less work is needed when
those same (sub?) expressions are next evaluated.
I believe most of the benefits won't be realized until we jump through a
number of hoops in our use of ognl that we've yet to implement in
xwork2/struts2, but if this (possibly premature) "upgrade" actively
slows down ognl evaluation, I'd like to know. (Since I swapped in these
more recent ognl version in the project I'm currently developing, I'd
really like to know if that was a step backwards.)
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] Slow performance with Struts2
Posted by yorlick kilroy <wg...@gmail.com>.
I'm sorry but I only just read about javassist now, as I had no idea what it
is nor does. How do I include it? do I just drop it in my lib folder like I
do with other Struts plugins? How do I use it? and what exactly does it do?
On Tue, Jul 1, 2008 at 1:22 AM, DNewfield <Da...@newfield.org> wrote:
>
> yorlick kilroy wrote:
> > thx! you made my day :-) that did the trick!
> > replacing freemarker 2.3.8 with 2.3.13 speeded up my application by
> almost
> > 100%
>
> Could you re-run your OGNL 2.6.11 vs. 2.7.2 tests with freemarker 2.3.13 in
> place, and see if the "upgrade" is still a performance "downgrade" as your
> previous tests indicated? (Did you include javassist?)
>
> -Dale
> --
> View this message in context:
> http://www.nabble.com/Slow-performance-with-Struts2-tp18092204p18206304.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: [struts] Slow performance with Struts2
Posted by DNewfield <Da...@Newfield.org>.
yorlick kilroy wrote:
> thx! you made my day :-) that did the trick!
> replacing freemarker 2.3.8 with 2.3.13 speeded up my application by almost
> 100%
Could you re-run your OGNL 2.6.11 vs. 2.7.2 tests with freemarker 2.3.13 in
place, and see if the "upgrade" is still a performance "downgrade" as your
previous tests indicated? (Did you include javassist?)
-Dale
--
View this message in context: http://www.nabble.com/Slow-performance-with-Struts2-tp18092204p18206304.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] Slow performance with Struts2
Posted by yorlick kilroy <wg...@gmail.com>.
On Fri, Jun 27, 2008 at 7:25 AM, yorlick kilroy <wg...@gmail.com> wrote:
> Hi Al,
>
> thx! you made my day :-) that did the trick!
> replacing freemarker 2.3.8 with 2.3.13 speeded up my application by almost
> 100%
> It still doesn't come anywhere near my old struts2 application but I guess
> its a fairly small trade-off when considering what struts2 has to offer.
correction: I meant "old Struts1 application" not Struts2
>
> --- joe
>
>
> On Thu, Jun 26, 2008 at 5:09 PM, Al Sutton <al...@alsutton.com> wrote:
>
>> If your benchmark uses multiple threads throw in a freemarker upgrade to
>> 2.3.13 and have another spin :).
>>
>> One thing you might want to bear in mind is that if you're using a
>> persistance framework there maybe some back end fetching taking place
>> between a.b.c and a.b.c.d. Even though you write simple beans and accessors
>> you can't guarentee whats happening to your objects under the covers.
>>
>> Al.
>>
>>
>> yorlick kilroy wrote:
>>
>>> I replaced OGNL 2.6.11 with the latest 2.7.2 Version.
>>> I did a bit of benchmarking comparing the two and it absolutely surprised
>>> me, that 2.7.2 in some cases is almost twice as slow as 2.6.11
>>> The test scenario:
>>> iterate a large java.util.List in a jsp. the List contains a pretty
>>> large
>>> tree of objects. in the jsp I access a String property in the last node
>>> of
>>> this object graph. OGNL 2.6.11 takes roughly 600 ms to complete, 2.7.2
>>> roughly 1050 ms
>>>
>>> From that I gather that OGNL wasn't designed for high performance when
>>> processing large and complex object trees in jsps. I guess I'll have to
>>> go
>>> back and do it like in the old Struts1 days: use shallow objects like in
>>> ActionForms
>>>
>>> On Wed, Jun 25, 2008 at 8:31 PM, Dale Newfield <Da...@newfield.org>
>>> wrote:
>>>
>>>
>>>
>>>> yorlick kilroy wrote:
>>>>
>>>>
>>>>
>>>>> Still... the "problem" seems to be the OGNL implementation in struts2.
>>>>>
>>>>>
>>>>>
>>>> I'm guessing here, but maybe your issues are related to:
>>>>
>>>> http://jira.opensymphony.com/browse/OGNL-141
>>>>
>>>> Which has been pushed off in Xwork to 2.5:
>>>>
>>>> http://jira.opensymphony.com/browse/XW-631
>>>>
>>>> And which has been pushed off in Struts2 until at least 2.1.3:
>>>>
>>>> https://issues.apache.org/struts/browse/WW-2128
>>>>
>>>> You're welcome to update the version of ognl you're using in your own
>>>> app
>>>> (but remember to add javassist if so).
>>>>
>>>> <s:iterate ... >
>>>>
>>>>
>>>>> <s:property value="#object.a.b.c.name"/>
>>>>> <s:property value="#object.a.b.c.phone"/>
>>>>> </s:iterate>
>>>>>
>>>>>
>>>>>
>>>> Theoretically this translates to a straight lookup for #object, then
>>>> getA().getB().getC().getName()...
>>>> If A, B, and C are just accessors, it should be fast. If they do much
>>>> work
>>>> to determine what to return, you're doing that work 2*N times (where N
>>>> is
>>>> the number of times through the loop) instead of just once...why would
>>>> you
>>>> put a long lookup like that in an iterator if it doesn't change with
>>>> each
>>>> iteration?
>>>>
>>>> -Dale
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
Re: [struts] Slow performance with Struts2
Posted by yorlick kilroy <wg...@gmail.com>.
Hi Al,
thx! you made my day :-) that did the trick!
replacing freemarker 2.3.8 with 2.3.13 speeded up my application by almost
100%
It still doesn't come anywhere near my old struts2 application but I guess
its a fairly small trade-off when considering what struts2 has to offer.
--- joe
On Thu, Jun 26, 2008 at 5:09 PM, Al Sutton <al...@alsutton.com> wrote:
> If your benchmark uses multiple threads throw in a freemarker upgrade to
> 2.3.13 and have another spin :).
>
> One thing you might want to bear in mind is that if you're using a
> persistance framework there maybe some back end fetching taking place
> between a.b.c and a.b.c.d. Even though you write simple beans and accessors
> you can't guarentee whats happening to your objects under the covers.
>
> Al.
>
>
> yorlick kilroy wrote:
>
>> I replaced OGNL 2.6.11 with the latest 2.7.2 Version.
>> I did a bit of benchmarking comparing the two and it absolutely surprised
>> me, that 2.7.2 in some cases is almost twice as slow as 2.6.11
>> The test scenario:
>> iterate a large java.util.List in a jsp. the List contains a pretty large
>> tree of objects. in the jsp I access a String property in the last node of
>> this object graph. OGNL 2.6.11 takes roughly 600 ms to complete, 2.7.2
>> roughly 1050 ms
>>
>> From that I gather that OGNL wasn't designed for high performance when
>> processing large and complex object trees in jsps. I guess I'll have to go
>> back and do it like in the old Struts1 days: use shallow objects like in
>> ActionForms
>>
>> On Wed, Jun 25, 2008 at 8:31 PM, Dale Newfield <Da...@newfield.org> wrote:
>>
>>
>>
>>> yorlick kilroy wrote:
>>>
>>>
>>>
>>>> Still... the "problem" seems to be the OGNL implementation in struts2.
>>>>
>>>>
>>>>
>>> I'm guessing here, but maybe your issues are related to:
>>>
>>> http://jira.opensymphony.com/browse/OGNL-141
>>>
>>> Which has been pushed off in Xwork to 2.5:
>>>
>>> http://jira.opensymphony.com/browse/XW-631
>>>
>>> And which has been pushed off in Struts2 until at least 2.1.3:
>>>
>>> https://issues.apache.org/struts/browse/WW-2128
>>>
>>> You're welcome to update the version of ognl you're using in your own app
>>> (but remember to add javassist if so).
>>>
>>> <s:iterate ... >
>>>
>>>
>>>> <s:property value="#object.a.b.c.name"/>
>>>> <s:property value="#object.a.b.c.phone"/>
>>>> </s:iterate>
>>>>
>>>>
>>>>
>>> Theoretically this translates to a straight lookup for #object, then
>>> getA().getB().getC().getName()...
>>> If A, B, and C are just accessors, it should be fast. If they do much
>>> work
>>> to determine what to return, you're doing that work 2*N times (where N is
>>> the number of times through the loop) instead of just once...why would
>>> you
>>> put a long lookup like that in an iterator if it doesn't change with each
>>> iteration?
>>>
>>> -Dale
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: [struts] Slow performance with Struts2
Posted by Al Sutton <al...@alsutton.com>.
If your benchmark uses multiple threads throw in a freemarker upgrade to
2.3.13 and have another spin :).
One thing you might want to bear in mind is that if you're using a
persistance framework there maybe some back end fetching taking place
between a.b.c and a.b.c.d. Even though you write simple beans and
accessors you can't guarentee whats happening to your objects under the
covers.
Al.
yorlick kilroy wrote:
> I replaced OGNL 2.6.11 with the latest 2.7.2 Version.
> I did a bit of benchmarking comparing the two and it absolutely surprised
> me, that 2.7.2 in some cases is almost twice as slow as 2.6.11
> The test scenario:
> iterate a large java.util.List in a jsp. the List contains a pretty large
> tree of objects. in the jsp I access a String property in the last node of
> this object graph. OGNL 2.6.11 takes roughly 600 ms to complete, 2.7.2
> roughly 1050 ms
>
> From that I gather that OGNL wasn't designed for high performance when
> processing large and complex object trees in jsps. I guess I'll have to go
> back and do it like in the old Struts1 days: use shallow objects like in
> ActionForms
>
> On Wed, Jun 25, 2008 at 8:31 PM, Dale Newfield <Da...@newfield.org> wrote:
>
>
>> yorlick kilroy wrote:
>>
>>
>>> Still... the "problem" seems to be the OGNL implementation in struts2.
>>>
>>>
>> I'm guessing here, but maybe your issues are related to:
>>
>> http://jira.opensymphony.com/browse/OGNL-141
>>
>> Which has been pushed off in Xwork to 2.5:
>>
>> http://jira.opensymphony.com/browse/XW-631
>>
>> And which has been pushed off in Struts2 until at least 2.1.3:
>>
>> https://issues.apache.org/struts/browse/WW-2128
>>
>> You're welcome to update the version of ognl you're using in your own app
>> (but remember to add javassist if so).
>>
>> <s:iterate ... >
>>
>>> <s:property value="#object.a.b.c.name"/>
>>> <s:property value="#object.a.b.c.phone"/>
>>> </s:iterate>
>>>
>>>
>> Theoretically this translates to a straight lookup for #object, then
>> getA().getB().getC().getName()...
>> If A, B, and C are just accessors, it should be fast. If they do much work
>> to determine what to return, you're doing that work 2*N times (where N is
>> the number of times through the loop) instead of just once...why would you
>> put a long lookup like that in an iterator if it doesn't change with each
>> iteration?
>>
>> -Dale
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] Slow performance with Struts2
Posted by yorlick kilroy <wg...@gmail.com>.
I replaced OGNL 2.6.11 with the latest 2.7.2 Version.
I did a bit of benchmarking comparing the two and it absolutely surprised
me, that 2.7.2 in some cases is almost twice as slow as 2.6.11
The test scenario:
iterate a large java.util.List in a jsp. the List contains a pretty large
tree of objects. in the jsp I access a String property in the last node of
this object graph. OGNL 2.6.11 takes roughly 600 ms to complete, 2.7.2
roughly 1050 ms
>From that I gather that OGNL wasn't designed for high performance when
processing large and complex object trees in jsps. I guess I'll have to go
back and do it like in the old Struts1 days: use shallow objects like in
ActionForms
On Wed, Jun 25, 2008 at 8:31 PM, Dale Newfield <Da...@newfield.org> wrote:
> yorlick kilroy wrote:
>
>> Still... the "problem" seems to be the OGNL implementation in struts2.
>>
>
> I'm guessing here, but maybe your issues are related to:
>
> http://jira.opensymphony.com/browse/OGNL-141
>
> Which has been pushed off in Xwork to 2.5:
>
> http://jira.opensymphony.com/browse/XW-631
>
> And which has been pushed off in Struts2 until at least 2.1.3:
>
> https://issues.apache.org/struts/browse/WW-2128
>
> You're welcome to update the version of ognl you're using in your own app
> (but remember to add javassist if so).
>
> <s:iterate ... >
>> <s:property value="#object.a.b.c.name"/>
>> <s:property value="#object.a.b.c.phone"/>
>> </s:iterate>
>>
>
> Theoretically this translates to a straight lookup for #object, then
> getA().getB().getC().getName()...
> If A, B, and C are just accessors, it should be fast. If they do much work
> to determine what to return, you're doing that work 2*N times (where N is
> the number of times through the loop) instead of just once...why would you
> put a long lookup like that in an iterator if it doesn't change with each
> iteration?
>
> -Dale
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>