Slow performance with Struts2

[yorlick kilroy-2]

Hi,

I was wondering if there is a way to tweak struts2 performance.
I ported an old struts1 application to struts2. I have jsps that have
rather large and complex lists that I now iterate using Struts2
<s:iterate> and OGNL instead of <logic:iterate> and EL used in
struts1. I noticed that the performance using Struts2 is pretty much
lower than that of the Struts1 application, especially when displaying
large lists and descending into complex objects using OGNL.
I read that using dojo can cause this, but as far as I know I'm not
(consciously) using dogo, ajax etc. just plain struts2 core.

-- Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[newton.dave]

http://struts.apache.org/2.x/docs/performance-tuning.html

Dave


--- On Tue, 6/24/08, yorlick kilroy <wgtlogs@...> wrote:

> From: yorlick kilroy <wgtlogs@...>
> Subject: Slow performance with Struts2
> To: user@...
> Date: Tuesday, June 24, 2008, 10:23 AM
> Hi,
>
> I was wondering if there is a way to tweak struts2
> performance.
> I ported an old struts1 application to struts2. I have jsps
> that have
> rather large and complex lists that I now iterate using
> Struts2
> <s:iterate> and OGNL instead of <logic:iterate>
> and EL used in
> struts1. I noticed that the performance using Struts2 is
> pretty much
> lower than that of the Struts1 application, especially when
> displaying
> large lists and descending into complex objects using OGNL.
> I read that using dojo can cause this, but as far as I know
> I'm not
> (consciously) using dogo, ajax etc. just plain struts2
> core.
>
> -- Joe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail:
> user-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[yorlick kilroy-2]

Thanks for the performance-tuning links Dave. I Found a couple of
useful hints there.
Still... the "problem" seems to be the OGNL implementation in struts2.
It seems to me as if one should be VERY careful when using OGNL i.e.
make use of it very sparingly. in some of my jsps I descend fairly
deeply into my complex value objects consisting of maps and lists etc.
I dont have any benchmark results but it "feels" like the time taken
to render a jsp with lots of OGNL expressions increases exponentially
proportional to the depth of the used OGNL expression, for example:

<s:iterate ... >
     <s:property value="#object.a.b.c.name"/>
     <s:property value="#object.a.b.c.phone"/>
</s:iterate>

Which isn't a performance problem when writing the above code in pure
java - only when done in struts2 OGNL

Can anyone confirm this?

Perhaps OGNL is only meant to be used for accessing only immediate
properties of an object and not to descend down into complex
tree-object-graphs.?

--- Joe

On 6/24/08, Dave Newton <newton.dave@...> wrote:

> http://struts.apache.org/2.x/docs/performance-tuning.html
>
> Dave
>
>
> --- On Tue, 6/24/08, yorlick kilroy <wgtlogs@...> wrote:
>
>> From: yorlick kilroy <wgtlogs@...>
>> Subject: Slow performance with Struts2
>> To: user@...
>> Date: Tuesday, June 24, 2008, 10:23 AM
>> Hi,
>>
>> I was wondering if there is a way to tweak struts2
>> performance.
>> I ported an old struts1 application to struts2. I have jsps
>> that have
>> rather large and complex lists that I now iterate using
>> Struts2
>> <s:iterate> and OGNL instead of <logic:iterate>
>> and EL used in
>> struts1. I noticed that the performance using Struts2 is
>> pretty much
>> lower than that of the Struts1 application, especially when
>> displaying
>> large lists and descending into complex objects using OGNL.
>> I read that using dojo can cause this, but as far as I know
>> I'm not
>> (consciously) using dogo, ajax etc. just plain struts2
>> core.
>>
>> -- Joe
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@...
>> For additional commands, e-mail:
>> user-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Paweł Wielgus]

Hi Joe,
i had similiar problem in struts

On 25/06/2008, yorlick kilroy <wgtlogs@...> wrote:

> Thanks for the performance-tuning links Dave. I Found a couple of
>  useful hints there.
>  Still... the "problem" seems to be the OGNL implementation in struts2.
>  It seems to me as if one should be VERY careful when using OGNL i.e.
>  make use of it very sparingly. in some of my jsps I descend fairly
>  deeply into my complex value objects consisting of maps and lists etc.
>  I dont have any benchmark results but it "feels" like the time taken
>  to render a jsp with lots of OGNL expressions increases exponentially
>  proportional to the depth of the used OGNL expression, for example:
>
>  <s:iterate ... >
>      <s:property value="#object.a.b.c.name"/>
>      <s:property value="#object.a.b.c.phone"/>
>  </s:iterate>
>
>  Which isn't a performance problem when writing the above code in pure
>  java - only when done in struts2 OGNL
>
>  Can anyone confirm this?
>
>  Perhaps OGNL is only meant to be used for accessing only immediate
>  properties of an object and not to descend down into complex
>  tree-object-graphs.?
>
>  --- Joe
>
>  On 6/24/08, Dave Newton <newton.dave@...> wrote:
>  > http://struts.apache.org/2.x/docs/performance-tuning.html
>  >
>  > Dave
>  >
>  >
>  > --- On Tue, 6/24/08, yorlick kilroy <wgtlogs@...> wrote:
>  >
>  >> From: yorlick kilroy <wgtlogs@...>
>  >> Subject: Slow performance with Struts2
>  >> To: user@...
>  >> Date: Tuesday, June 24, 2008, 10:23 AM
>  >> Hi,
>  >>
>  >> I was wondering if there is a way to tweak struts2
>  >> performance.
>  >> I ported an old struts1 application to struts2. I have jsps
>  >> that have
>  >> rather large and complex lists that I now iterate using
>  >> Struts2
>  >> <s:iterate> and OGNL instead of <logic:iterate>
>  >> and EL used in
>  >> struts1. I noticed that the performance using Struts2 is
>  >> pretty much
>  >> lower than that of the Struts1 application, especially when
>  >> displaying
>  >> large lists and descending into complex objects using OGNL.
>  >> I read that using dojo can cause this, but as far as I know
>  >> I'm not
>  >> (consciously) using dogo, ajax etc. just plain struts2
>  >> core.
>  >>
>  >> -- Joe
>  >>
>  >> ---------------------------------------------------------------------
>  >> To unsubscribe, e-mail: user-unsubscribe@...
>  >> For additional commands, e-mail:
>  >> user-help@...
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: user-unsubscribe@...
>  > For additional commands, e-mail: user-help@...
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: user-unsubscribe@...
>  For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Paweł Wielgus]

Hi Joe,
sorry for the previus post, too fast fingers ;-)
Long time ago I had similiar problem in struts 1, when accesing lists
with logic:iterate it turned out that if i used <logic:iterate
name="bean" property="myList"> and this getMyList() method was not
really a getter but some logic that was building myList, logic:iterate
was accesing myList like getMyList().get(0), then getMyList().get(1)
and so on. Which obvoiusly kills the performance. I'm not using such
getters since then, but that may be the case in s2 also.

Best greetings,
Paweł Wielgus.

On 25/06/2008, Paweł Wielgus <poulwiel@...> wrote:

> Hi Joe,
>  i had similiar problem in struts
>
>
>  On 25/06/2008, yorlick kilroy <wgtlogs@...> wrote:
>  > Thanks for the performance-tuning links Dave. I Found a couple of
>  >  useful hints there.
>  >  Still... the "problem" seems to be the OGNL implementation in struts2.
>  >  It seems to me as if one should be VERY careful when using OGNL i.e.
>  >  make use of it very sparingly. in some of my jsps I descend fairly
>  >  deeply into my complex value objects consisting of maps and lists etc.
>  >  I dont have any benchmark results but it "feels" like the time taken
>  >  to render a jsp with lots of OGNL expressions increases exponentially
>  >  proportional to the depth of the used OGNL expression, for example:
>  >
>  >  <s:iterate ... >
>  >      <s:property value="#object.a.b.c.name"/>
>  >      <s:property value="#object.a.b.c.phone"/>
>  >  </s:iterate>
>  >
>  >  Which isn't a performance problem when writing the above code in pure
>  >  java - only when done in struts2 OGNL
>  >
>  >  Can anyone confirm this?
>  >
>  >  Perhaps OGNL is only meant to be used for accessing only immediate
>  >  properties of an object and not to descend down into complex
>  >  tree-object-graphs.?
>  >
>  >  --- Joe
>  >
>  >  On 6/24/08, Dave Newton <newton.dave@...> wrote:
>  >  > http://struts.apache.org/2.x/docs/performance-tuning.html
>  >  >
>  >  > Dave
>  >  >
>  >  >
>  >  > --- On Tue, 6/24/08, yorlick kilroy <wgtlogs@...> wrote:
>  >  >
>  >  >> From: yorlick kilroy <wgtlogs@...>
>  >  >> Subject: Slow performance with Struts2
>  >  >> To: user@...
>  >  >> Date: Tuesday, June 24, 2008, 10:23 AM
>  >  >> Hi,
>  >  >>
>  >  >> I was wondering if there is a way to tweak struts2
>  >  >> performance.
>  >  >> I ported an old struts1 application to struts2. I have jsps
>  >  >> that have
>  >  >> rather large and complex lists that I now iterate using
>  >  >> Struts2
>  >  >> <s:iterate> and OGNL instead of <logic:iterate>
>  >  >> and EL used in
>  >  >> struts1. I noticed that the performance using Struts2 is
>  >  >> pretty much
>  >  >> lower than that of the Struts1 application, especially when
>  >  >> displaying
>  >  >> large lists and descending into complex objects using OGNL.
>  >  >> I read that using dojo can cause this, but as far as I know
>  >  >> I'm not
>  >  >> (consciously) using dogo, ajax etc. just plain struts2
>  >  >> core.
>  >  >>
>  >  >> -- Joe
>  >  >>
>  >  >> ---------------------------------------------------------------------
>  >  >> To unsubscribe, e-mail: user-unsubscribe@...
>  >  >> For additional commands, e-mail:
>  >  >> user-help@...
>  >  >
>  >  > ---------------------------------------------------------------------
>  >  > To unsubscribe, e-mail: user-unsubscribe@...
>  >  > For additional commands, e-mail: user-help@...
>  >  >
>  >  >
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: user-unsubscribe@...
>  >  For additional commands, e-mail: user-help@...
>  >
>  >
>

[DNewfield]

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@...
For additional commands, e-mail: user-help@...

[yorlick kilroy-2]

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 <Dale@...> 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@...
> For additional commands, e-mail: user-help@...
>
>

[Al Sutton]

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 <Dale@...> 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@...
>> For additional commands, e-mail: user-help@...
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[yorlick kilroy-2]

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.sutton@...> 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 <Dale@...> 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@...
>>> For additional commands, e-mail: user-help@...
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

[yorlick kilroy-2]

On Fri, Jun 27, 2008 at 7:25 AM, yorlick kilroy <wgtlogs@...> 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.sutton@...> 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 <Dale@...>
>>> 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@...
>>>> For additional commands, e-mail: user-help@...
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@...
>> For additional commands, e-mail: user-help@...
>>
>>
>

[DNewfield]

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

[yorlick kilroy-2]

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 <Dale@...> 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@...
> For additional commands, e-mail: user-help@...
>
>

[DNewfield]

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@...
For additional commands, e-mail: user-help@...

[yorlick kilroy-2]

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 <Dale@...> 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@...
> For additional commands, e-mail: user-help@...
>
>

[DNewfield]

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@...
For additional commands, e-mail: user-help@...

[matt.payne]

Use firebug to measure you http.  Firebug will give you a detail view of what resources (e.g. dojo) are being pulled down with the http traffic.

Matt

yorlick kilroy-2 wrote:

Hi,

I was wondering if there is a way to tweak struts2 performance.
I ported an old struts1 application to struts2. I have jsps that have
rather large and complex lists that I now iterate using Struts2
<s:iterate> and OGNL instead of <logic:iterate> and EL used in
struts1. I noticed that the performance using Struts2 is pretty much
lower than that of the Struts1 application, especially when displaying
large lists and descending into complex objects using OGNL.
I read that using dojo can cause this, but as far as I know I'm not
(consciously) using dogo, ajax etc. just plain struts2 core.

-- Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[yorlick kilroy-2]

ok heres what I did:

I replaced all struts2 tags with standard JSTL Core tags in JSPs that
generate a lot of output. Now my JSPs load up to 20 times faster. The
only place where I use struts2 tags is in forms


On Mon, Jul 7, 2008 at 7:30 PM, matt.payne <matthew.b.payne@...> wrote:

>
> Use firebug to measure you http.  Firebug will give you a detail view of what
> resources (e.g. dojo) are being pulled down with the http traffic.
>
> Matt
>
>
> yorlick kilroy-2 wrote:
>>
>> Hi,
>>
>> I was wondering if there is a way to tweak struts2 performance.
>> I ported an old struts1 application to struts2. I have jsps that have
>> rather large and complex lists that I now iterate using Struts2
>> <s:iterate> and OGNL instead of <logic:iterate> and EL used in
>> struts1. I noticed that the performance using Struts2 is pretty much
>> lower than that of the Struts1 application, especially when displaying
>> large lists and descending into complex objects using OGNL.
>> I read that using dojo can cause this, but as far as I know I'm not
>> (consciously) using dogo, ajax etc. just plain struts2 core.
>>
>> -- Joe
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@...
>> For additional commands, e-mail: user-help@...
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Slow-performance-with-Struts2-tp18092204p18323440.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...