Struts 2 performance

[climbingrose]

Hi all,

I've been developing Struts 2 webapp for nearly a year now and have a great
deal of experience with it. Personally, the architecture of Struts 2 is much
cleaner than its predecessor. However, recently I converted one of my Struts
2 pages into Servlet + JSP solution and it turns out that Struts 2
performance is much worse than Servlet + JSP. In Servlet + JSP solution, the
server CPU is barely over 3-4% while with Struts 2, it's around 70% most of
the time. The JSP page is around 300 lines of code. I don't have a chance to
do any profiling to find out where is the bottleneck but I suspect it might
be OGNL which hinders the performance. I think, we already have a pretty
good feature set so we can start thinking about optimising Struts 2. That
will probably speed up its adoption in the industry.

The other thing I want to comment on is the use of Dojo as Ajax theme. I
don't have much experience with Dojo apart from a few hours playing around
with it. However, even with the latest version (0.9), Dojo just seems to be
to heavy weight for most purposes. I mean if you only want a bloody calendar
in your webapp, you don't want to load up a 100kb of  javascript. Plus, it
might be my experience only, Dojo seems to have the tendency to hang my
browser everytime I open a Dojo-based app.

--
Regards,

Cuong Hoang

[Frank W. Zammetti]

climbingrose wrote:
>
> The other thing I want to comment on is the use of Dojo as Ajax theme. I
> don't have much experience with Dojo apart from a few hours playing around
> with it. However, even with the latest version (0.9), Dojo just seems to be
> to heavy weight for most purposes. I mean if you only want a bloody
> calendar
> in your webapp, you don't want to load up a 100kb of  javascript.

This has been my experience with Dojo as well, to the point where we're
now considering ripping Dojo out of a very highly complex project bit by
bit (too much pain in doing it all at once).  Nothing has been decided
yet because we still believe Dojo has a lot to offer that makes it not a
clear-cut decision, but your description is, in my experience, fairly
accurate.

 > Plus, it
> might be my experience only, Dojo seems to have the tendency to hang my
> browser everytime I open a Dojo-based app.

This, however, doesn't jive with my experience.  As I mentioned, I have
one app using Dojo that is extremely complex, and I don't recall ever
seeing it lock up the browser.  We *have* had issues with memory
consumption, but I can't say for certain yet whether it's Dojo (suspect
it is at this point), and it's possible we're doing something wrong to
cause it and not Dojo intrinsically having a problem.  If your seeing
lockups, it might be helpful to know that this isn't typical, based on
my experience with it.

In any case, my understanding is that the Ajax theme is being extracted
out into a plugin specifically so that other libraries can be used in
place of Dojo.  While I think Dojo will still get a great deal of usage
and attention, I think giving that flexibility will be a welcome move.

Frank

--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
  (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
  (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
  Supplying the wheel, so you don't have to reinvent it!

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

[Ted Husted]

On 7/9/07, Frank W. Zammetti <fzlists@...> wrote:
> In any case, my understanding is that the Ajax theme is being extracted
> out into a plugin specifically so that other libraries can be used in
> place of Dojo.  While I think Dojo will still get a great deal of usage
> and attention, I think giving that flexibility will be a welcome move.

Yes, moving Ajax support from themes to plugins is on the 2.1.x
roadmap. In fact a YUI plugin is already available for Struts 2.0.x

 * http://cwiki.apache.org/S2PLUGINS/yui-plugin.html

-Ted.

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

[Ted Husted]

On 7/9/07, climbingrose <climbingrose@...> wrote:
>I don't have a chance to do any profiling to find out where is the bottleneck

Before trying any profiling, be sure to follow the tips at
<http://struts.apache.org/2.x/docs/performance-tuning.html>.

 -Ted.

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

[Lionel-6]

climbingrose wrote:
> Dojo just seems to be to heavy weight for most purposes. I mean if
> you only want a bloody calendar in your webapp, you don't want to
> load up a 100kb of  javascript. Plus, it might be my experience only,
> Dojo seems to have the tendency to hang my browser everytime I open a
> Dojo-based app.

I've been using dojo for more than 1 year.
I had huge performance concerns (but no hang).
The only solution was to disable parseWidget and add widgets using
dojo.widget.createWidget.
Also use gzip compression on *.js.
This way, every thing works pretty fine.
If it's not possible with struts 2, stay far away from the ajax theme...





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

[climbingrose]

Well, I prefer using Javascript library like JQuery or Mootools for Ajax
rather than Dojo. With JQuery I only have 10kB after compressing with gzip.

On 7/11/07, Lionel <lionel@...> wrote:

>
> climbingrose wrote:
> > Dojo just seems to be to heavy weight for most purposes. I mean if
> > you only want a bloody calendar in your webapp, you don't want to
> > load up a 100kb of  javascript. Plus, it might be my experience only,
> > Dojo seems to have the tendency to hang my browser everytime I open a
> > Dojo-based app.
>
> I've been using dojo for more than 1 year.
> I had huge performance concerns (but no hang).
> The only solution was to disable parseWidget and add widgets using
> dojo.widget.createWidget.
> Also use gzip compression on *.js.
> This way, every thing works pretty fine.
> If it's not possible with struts 2, stay far away from the ajax theme...
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

--
Regards,

Cuong Hoang

[cilquirm]

I've found that static html pages are blazing fast, especially those that don't involve stylesheets, images, or javascript includes.  :-)

Seriously, though, I don't think there's any disagreement that ognl ( or any runtime expression language ) adds a certain amount of overhead, but I've never seen any of my servers pinned that high, and I've been working with WW2/S2 for probably around 3 years now.

At the end of the day, I can argue to my company that we'll get faster performance by switching to servlets and straight jsp, but I don't want to be the one debugging that when it all goes to pot. I'm all for the minor tradeoff on performance for the incredibly superior gains in productivity and general developer happiness that S2 affords me.

my2c,
-a

P.S.  One thing you can do, if you're so inclined once you've tried out the other performance tips, is to give ognl 2.7 a go.  You can get it via the Tapestry libs download.  It's a straightforward replacement, just drop in  ognl.jar and javassist.jar and start up.  

I've done it here and it hasn't really changed my perception of my webapp but YMMV

climbingrose wrote:

Hi all,

I've been developing Struts 2 webapp for nearly a year now and have a great
deal of experience with it. Personally, the architecture of Struts 2 is much
cleaner than its predecessor. However, recently I converted one of my Struts
2 pages into Servlet + JSP solution and it turns out that Struts 2
performance is much worse than Servlet + JSP. In Servlet + JSP solution, the
server CPU is barely over 3-4% while with Struts 2, it's around 70% most of
the time. The JSP page is around 300 lines of code. I don't have a chance to
do any profiling to find out where is the bottleneck but I suspect it might
be OGNL which hinders the performance. I think, we already have a pretty
good feature set so we can start thinking about optimising Struts 2. That
will probably speed up its adoption in the industry.



The other thing I want to comment on is the use of Dojo as Ajax theme. I
don't have much experience with Dojo apart from a few hours playing around
with it. However, even with the latest version (0.9), Dojo just seems to be
to heavy weight for most purposes. I mean if you only want a bloody calendar
in your webapp, you don't want to load up a 100kb of  javascript. Plus, it
might be my experience only, Dojo seems to have the tendency to hang my
browser everytime I open a Dojo-based app.

--
Regards,

Cuong Hoang

[climbingrose]

Obviously as a Struts 2 user I see the benefit of the framework. I actually
convinced my company to abandon Struts 1 and go forward with Struts 2.
However, I really think you need to consider carefully where you should use
the the framework. From my own experience, I tend to develop "public pages"
in JSP + Servlet because I want performance on these pages and I know that
they are hit heavily everyday. For example, in ecommerce apps, pages mostly
visited are the catalog ones. Considering the number of hits these pages
receive, if you can squeeze 5x performance improvement out of them, it'll
make a big different. However, for the administrative pages, you probably
can go with Struts 2 because they don't get hit heavily and users of these
pages tend to be more patient. So it all depends on your app's usage
patterns and your architecture. That's my 2 cents. Your experience might be
different though and please share it if you don't mind.

On 7/11/07, cilquirm <aadi.deshpande@...> wrote:

>
>
> I've found that static html pages are blazing fast, especially those that
> don't involve stylesheets, images, or javascript includes.  :-)
>
> Seriously, though, I don't think there's any disagreement that ognl ( or
> any
> runtime expression language ) adds a certain amount of overhead, but I've
> never seen any of my servers pinned that high, and I've been working with
> WW2/S2 for probably around 3 years now.
>
> At the end of the day, I can argue to my company that we'll get faster
> performance by switching to servlets and straight jsp, but I don't want to
> be the one debugging that when it all goes to pot. I'm all for the minor
> tradeoff on performance for the incredibly superior gains in productivity
> and general developer happiness that S2 affords me.
>
> my2c,
> -a
>
> P.S.  One thing you can do, if you're so inclined once you've tried out
> the
> other performance tips, is to give ognl 2.7 a go.  You can get it via the
> Tapestry libs download.  It's a straightforward replacement, just drop in
> ognl.jar and javassist.jar and start up.
>
> I've done it here and it hasn't really changed my perception of my webapp
> but YMMV
>
>
>
> climbingrose wrote:
> >
> > Hi all,
> >
> > I've been developing Struts 2 webapp for nearly a year now and have a
> > great
> > deal of experience with it. Personally, the architecture of Struts 2 is
> > much
> > cleaner than its predecessor. However, recently I converted one of my
> > Struts
> > 2 pages into Servlet + JSP solution and it turns out that Struts 2
> > performance is much worse than Servlet + JSP. In Servlet + JSP solution,
> > the
> > server CPU is barely over 3-4% while with Struts 2, it's around 70% most
> > of
> > the time. The JSP page is around 300 lines of code. I don't have a
> chance
> > to
> > do any profiling to find out where is the bottleneck but I suspect it
> > might
> > be OGNL which hinders the performance. I think, we already have a pretty
> > good feature set so we can start thinking about optimising Struts 2.
> That
> > will probably speed up its adoption in the industry.
> >
> >
> >
> > The other thing I want to comment on is the use of Dojo as Ajax theme. I
> > don't have much experience with Dojo apart from a few hours playing
> around
> > with it. However, even with the latest version (0.9), Dojo just seems to
> > be
> > to heavy weight for most purposes. I mean if you only want a bloody
> > calendar
> > in your webapp, you don't want to load up a 100kb of  javascript. Plus,
> it
> > might be my experience only, Dojo seems to have the tendency to hang my
> > browser everytime I open a Dojo-based app.
> >
> > --
> > Regards,
> >
> > Cuong Hoang
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Struts-2-performance-tf4053401.html#a11524619
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

--
Regards,

Cuong Hoang

[Toni Lyytikäinen]

After playing around with Firebug a little I found out that in our project
the most costly thing in the page loading process is loading the dojo
.js-files. For some reason they are included in the xhtml theme too. If I
substitute

<s:head theme="xhtml" />

with

<link rel="stylesheet" href="/ikaros-webgui/struts/xhtml/styles.css"
type="text/css"/>

leaving out the dojo stuff, pages are loading really fast again. Is there
any reason besides the client side validation that the dojo includes are
needed for the xhtml theme?

[Don Brown-5]

Tooltips come to mind, and I think there is one other reason...maybe
it was the rich text editor.  Anyways, in 2.1 we pulled all
Dojo-related code into its own plugin, so it shouldn't affect the
xhtml theme anymore.

Don

On 7/11/07, Toni Lyytikäinen <tolyen@...> wrote:

> After playing around with Firebug a little I found out that in our project
> the most costly thing in the page loading process is loading the dojo
> .js-files. For some reason they are included in the xhtml theme too. If I
> substitute
>
> <s:head theme="xhtml" />
>
> with
>
> <link rel="stylesheet" href="/ikaros-webgui/struts/xhtml/styles.css"
> type="text/css"/>
>
> leaving out the dojo stuff, pages are loading really fast again. Is there
> any reason besides the client side validation that the dojo includes are
> needed for the xhtml theme?
>

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

[Aram Mkhitaryan]

Hi there,

This is really-really a very big problem.
The tests that passed for struts1
cant pass for struts2 even partially (even after lots of optimizations).

Struts2 is slow enough to use it for the big and popular sites.

Look here
https://issues.apache.org/struts/browse/WW-1673
and references there.
Maybe we can push those tickets to be fixed earlier,
since it is not clear when the mentioned version 2.1.x will be released.

Does someone know how we can do that?

Best,
Aram
________________________________
Aram Mkhitaryan

52, 25 Lvovyan, Yerevan 375000, Armenia

Mobile: [phone]
E-mail: aram.mkhitaryan@...

[Aram Mkhitaryan]

The problem is not just in dojo's js files and stuff like that.
Struts2 is too slow, >7-8x times than struts1

Best,
Aram
________________________________
Aram Mkhitaryan

52, 25 Lvovyan, Yerevan 375000, Armenia

Mobile: [phone]
E-mail: aram.mkhitaryan@...

[Leon Rosenberg-3]

On 7/11/07, Aram Mkhitaryan <aram.mkhitaryan@...> wrote:
> The problem is not just in dojo's js files and stuff like that.
> Struts2 is too slow, >7-8x times than struts1

Any reproduceable measurements which can support this statement?
Leon

>
> Best,
> Aram
> ________________________________
> Aram Mkhitaryan
>
> 52, 25 Lvovyan, Yerevan 375000, Armenia
>
> Mobile: [phone]
> E-mail: aram.mkhitaryan@...
>

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

[Aram Mkhitaryan]

There are load test results,

for struts1, up to 200 concurrent users with 0.75 sec timeout, result: 2%
timeout
for struts2, up to 10 concurrent users with 5 sec timeout, result: 80%
timeout

------------------------>>>

the application is the same, for struts2 ognl language is used,
but is optimized (ognl is replaced with simple struts/jsp tags where
possible)

I think this is enough to consider struts2 slow.

Best,
Aram

[DNewfield]

Don Brown wrote:
> Anyways, in 2.1 we pulled all Dojo-related code into its own plugin,
> so it shouldn't affect the xhtml theme anymore.

I'm looking forward to that :-)

I recognize that with any open source project timelines are difficult to
predict, but would you expect some version of 2.1 to be released in
weeks or months?  If you were forced to guess, do you think there's a
reasonable chance that it'll be available by, say, October?

-Dale

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

[Don Brown-5]

No idea about the 2.1 release, but if you don't use tooltips, just
override the xhtml header template, the one with the dojo import.
That should remove the dojo import and fix your issue for now.

Don

On 7/11/07, Dale Newfield <Dale@...> wrote:

> Don Brown wrote:
> > Anyways, in 2.1 we pulled all Dojo-related code into its own plugin,
> > so it shouldn't affect the xhtml theme anymore.
>
> I'm looking forward to that :-)
>
> I recognize that with any open source project timelines are difficult to
> predict, but would you expect some version of 2.1 to be released in
> weeks or months?  If you were forced to guess, do you think there's a
> reasonable chance that it'll be available by, say, October?
>
> -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@...

[Ted Husted]

On 7/11/07, Aram Mkhitaryan <aram.mkhitaryan@...> wrote:
> Look here
> https://issues.apache.org/struts/browse/WW-1673
> and references there.
> Maybe we can push those tickets to be fixed earlier,
> since it is not clear when the mentioned version 2.1.x will be released.
>
> Does someone know how we can do that?

I think the underlying problem is no one is sure how to proceed. There
have been several suggestion as to replacing OGNL and/or FreeMarker,
but no clear winner has emerged.

 * http://www.nabble.com/The-performance-issue-about-OGNL-tf3291137.html#a9154137

 * http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7825136

 * http://www.nabble.com/Abstracting-Ognl-from-XWork-and-Struts-2--tf2355393.html#a6561815

(and now)

 * http://www.nabble.com/Struts-2-performance-tf4053401.html#a11536097

Technology aside, the key ingredient is one or more volunteers who are
are ready, willing, and able to do the work.

A good place to start would be summarize the prior threads and post
the summary here and on the JIRA ticket.

We also could use a benchmark test that people in the project could
check out from SVN and run locally. We do have one contribution in
that regard, but it needs to be ported from WW to S2.

 * https://issues.apache.org/struts/browse/WW-1560

HTH, Ted.

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

[Musachy Barroso]

I think so far a couple of people have tried to decouple Struts 2 from OGNL,
(so other libs like MVEL could be used), so far no patch has made it through
:)

As for 2.1, the other day when Ted posted the numbers about the download
spike it made think that even with so many people downloading/using S2, we
are not getting many contributions/contributors and development overall
seems very slow. I know that's the nature of OSS, but we could use some help
right now.

regards
musachy

On 7/11/07, Ted Husted <husted@...> wrote:

>
> On 7/11/07, Aram Mkhitaryan <aram.mkhitaryan@...> wrote:
> > Look here
> > https://issues.apache.org/struts/browse/WW-1673
> > and references there.
> > Maybe we can push those tickets to be fixed earlier,
> > since it is not clear when the mentioned version 2.1.x will be released.
> >
> > Does someone know how we can do that?
>
> I think the underlying problem is no one is sure how to proceed. There
> have been several suggestion as to replacing OGNL and/or FreeMarker,
> but no clear winner has emerged.
>
> *
> http://www.nabble.com/The-performance-issue-about-OGNL-tf3291137.html#a9154137
>
> *
> http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7825136
>
> *
> http://www.nabble.com/Abstracting-Ognl-from-XWork-and-Struts-2--tf2355393.html#a6561815
>
> (and now)
>
> * http://www.nabble.com/Struts-2-performance-tf4053401.html#a11536097
>
> Technology aside, the key ingredient is one or more volunteers who are
> are ready, willing, and able to do the work.
>
> A good place to start would be summarize the prior threads and post
> the summary here and on the JIRA ticket.
>
> We also could use a benchmark test that people in the project could
> check out from SVN and run locally. We do have one contribution in
> that regard, but it needs to be ported from WW to S2.
>
> * https://issues.apache.org/struts/browse/WW-1560
>
> HTH, Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>

--
"Hey you! Would you help me to carry the stone?" Pink Floyd

[Andrea Vettori]

I'm using s2 2.0.8 on an e-commerce site. The site is very new so we  
have about 3000 sessions a day but I don't have performance  
problems... The pages are loading quickly. The most used pages are
- the products listing that gets data from a session bean and  
displays rows of information
- the product details that gets an xml from a session bean and  
displays it after transforming it with xslt.

Can anyone suggest how to "test" my site for performance analysis  
(best with a simple free product) ?
I can show here the result if interested.

I also think we should have a "test" application that minimizes  
memory/cpu utilization for non-struct components and some pre-defined  
tests so we can produce benchmarks we can compare...


--
Ing. Andrea Vettori
Consulente per l'Information Technology



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

[James Holmes-2]

It's not a simple JAR drop. The core XWork and Struts 2 libraries have to be
updated to compile expressions. This will take some work, but I believe it is
badly needed. I'm up for helping to do this work, but don't have much experience
with the OGNL code. I also don't have commit access to the XWork code.

What's the process for getting commit access to XWork for Struts committers?

James


On Wed Jul 11  9:39 , 'Guillaume Carré' <guillaume.carre@...> sent:

>2007/7/11, Musachy Barroso musachy@...>:
>> I think so far a couple of people have tried to decouple Struts 2 from OGNL,
>> (so other libs like MVEL could be used), so far no patch has made it through
>> :)
>
>have you considered upgrading to OGNL 2.7?
>
>Tapestry 4 did, there seems to be some performance improvement in this release:
>http://blog.opencomponentry.com/2007/06/26/tapestry-412-ognl-27-released/
>
>is it a simple JAR drop?
>--
>Guillaume Carré
>
>---------------------------------------------------------------------
>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@...