Re: Struts 2 performance
Did you try http://en.wikipedia.org/wiki/VisualVM Java VisualVM ? How does it compare to JRockit profiler? Musachy Barroso wrote: I would suggest you to use the profiler that comes with JRockit: http://www.oracle.com/technology/products/jrockit/index.html -- View this message in context: http://www.nabble.com/Struts-2-performance-tp24732029p24801034.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts 2 performance
sort of like a Lamborghini vs smart car :) On Mon, Aug 3, 2009 at 6:43 PM, Xyzrxyyzz...@gmail.com wrote: Did you try http://en.wikipedia.org/wiki/VisualVM Java VisualVM ? How does it compare to JRockit profiler? Musachy Barroso wrote: I would suggest you to use the profiler that comes with JRockit: http://www.oracle.com/technology/products/jrockit/index.html -- View this message in context: http://www.nabble.com/Struts-2-performance-tp24732029p24801034.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts 2 performance
Musachy Barroso wrote: Just to save you some time (because I just spend sometime myself on this), I would suggest you to use the profiler that comes with JRockit: http://www.oracle.com/technology/products/jrockit/index.html You will have to run your application with the JRockit jre to use it. It is free, and by far the best profiler I have ever used. I do all my development on a mac (not a platform for which this is available). I do have an old PC with *maybe* 1GB of memory that's dog slow already...do you think it's worth the hair I'll have to pull out in order to run my app in this and test it out? -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts 2 performance
If you have a commercial profiler that works on Mac, it could be good enough. But after I have been using it for a few days I was like whoaa this thing has improved a lot. It has a feature for profiling lock contention which is very sweet. musachy On Wed, Jul 29, 2009 at 11:38 PM, Dale Newfieldd...@newfield.org wrote: Musachy Barroso wrote: Just to save you some time (because I just spend sometime myself on this), I would suggest you to use the profiler that comes with JRockit: http://www.oracle.com/technology/products/jrockit/index.html You will have to run your application with the JRockit jre to use it. It is free, and by far the best profiler I have ever used. I do all my development on a mac (not a platform for which this is available). I do have an old PC with *maybe* 1GB of memory that's dog slow already...do you think it's worth the hair I'll have to pull out in order to run my app in this and test it out? -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: Struts 2 performance
detect lock contention on threads or connections? lock on something else? ? Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 30 Jul 2009 08:40:30 -0700 Subject: Re: Struts 2 performance From: musa...@gmail.com To: user@struts.apache.org If you have a commercial profiler that works on Mac, it could be good enough. But after I have been using it for a few days I was like whoaa this thing has improved a lot. It has a feature for profiling lock contention which is very sweet. musachy On Wed, Jul 29, 2009 at 11:38 PM, Dale Newfieldd...@newfield.org wrote: Musachy Barroso wrote: Just to save you some time (because I just spend sometime myself on this), I would suggest you to use the profiler that comes with JRockit: http://www.oracle.com/technology/products/jrockit/index.html You will have to run your application with the JRockit jre to use it. It is free, and by far the best profiler I have ever used. I do all my development on a mac (not a platform for which this is available). I do have an old PC with *maybe* 1GB of memory that's dog slow already...do you think it's worth the hair I'll have to pull out in order to run my app in this and test it out? -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org _ NEW mobile Hotmail. Optimized for YOUR phone. Click here. http://windowslive.com/Mobile?ocid=TXT_TAGLM_WL_CS_MB_new_hotmail_072009
Re: Struts 2 performance
Yes, and not. It is a good idea to remove any interceptor that you don't need, like i18n for example, or the double params if you are not using it. Before making any assumptions I would suggest you to profile your application, and see what is consuming the mos memory and time. Just to save you some time (because I just spend sometime myself on this), I would suggest you to use the profiler that comes with JRockit: http://www.oracle.com/technology/products/jrockit/index.html You will have to run your application with the JRockit jre to use it. It is free, and by far the best profiler I have ever used. With that in hand you can come back with some data, and then we can probably make some suggestions. Check this also: http://struts.apache.org/2.x/docs/performance-tuning.html musachy On Wed, Jul 29, 2009 at 9:33 PM, Say Jonwsay...@gmail.com wrote: Hi guys, I have been using Struts 2 for a while for some of my web apps. Performance is OK. I'm getting less than 400ms when I use the timerinterceptor for a regular retrieve operation. I'm just wondering, with the interceptor architecture it seems that there are many layers to go thru' when S2 is used. More so when we use the param, prepare, param pattern where the param interceptor is actually applied twice. Is this bad for memory consumption and execution speed? I'm also facing a problem when I deploy my S2 / Spring / Hibernate applications. Its sad that I almost have to get a min. of 512mb VPS for a fairly small - mid scale ecommerce application when my competitors in the market can deploy a PHP ecommerce application on a regular shared hosting which is much cheaper. Any similar experiences? Its really bad when we are talking about Java S2 + Spring + Hibernate hosting because the memory consumption is huge! All comments are welcomed! Regards. W.SayJon Email Disclaimer: The information contained in or attached to this email is confidential and solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, please notify the sender immediately and delete any copies of this email. Any unauthorised disclosure, copying, distribution or any action taken in reliance on the contents of this information is strictly prohibited and may be unlawful. -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: Struts 2 Performance
We are currently running on 2.0.11, have there been any performance improvements in subsequent releases? From: Matthew Seaborn Sent: 24 January 2009 13:39 To: Struts Users Mailing List Subject: Struts 2 Performance What's the latest news on the Struts 2 rendering performance issues? A browse through the issue log suggests that despite a number of releases it still hasn't been resolved. https://issues.apache.org/struts/browse/WW-2128 https://issues.apache.org/struts/browse/WW-2808 The proposed solution appears to be an upgrade to OGNL 2.7 but this doesn't appear to be planned until v2.5.xhttps://issues.apache.org/struts/browse/WW-2128?focusedCommentId=44204#action_44204. Matthew Seaborn Software Architect t+44(0) 208 484 0729 m +44(0) 7949 465 142 e matthew.seab...@performgroup.commailto:%3cyourname...@performgroup.com [cid:image001.jpg@01C97E2A.080A2AA0]http://www.performgroup.com/ Sussex House Plane Tree Crescent London, TW13 7HE United Kingdom www.performgroup.comhttp://www.performgroup.com/ [cid:image002.gif@01C97E2A.080A2AA0] http://www.omnisport.tv/ [cid:image003.gif@01C97E2A.080A2AA0] http://www.watchandbet.tv/ CONFIDENTIALITY - This email and any files transmitted with it, are confidential, may be legally privileged and are intended solely for the use of the individual or entity to whom they are addressed. If this has come to you in error, you must not copy, distribute, disclose or use any of the information it contains. Please notify the sender immediately and delete them from your system. SECURITY - Please be aware that communication by email, by its very nature, is not 100% secure and by communicating with Perform Group by email you consent to us monitoring and reading any such correspondence. VIRUSES - Although this email message has been scanned for the presence of computer viruses, the sender accepts no liability for any damage sustained as a result of a computer virus and it is the recipients responsibility to ensure that email is virus free. AUTHORITY - Any views or opinions expressed in this email are solely those of the sender and do not necessarily represent those of Perform Group. COPYRIGHT - Copyright of this email and any attachments belongs to Perform Group, Companies House Registration number 6324278.
Re: Struts 2 Performance
Thank you for the dojo info. I did a custom build for dojo using http://cwiki.apache.org/confluence/display/S2WIKI/Creating+a+custom+Dojo+profile+for+Struts+2.0.x and it reduced alot of requests I would like to turn off the page scan that dojo does and add the bootstrap code for the widgits my self. I'm not sure what to search for to find information on this. Can you point me to any articles or documentation? Thank you, Rich On Fri, May 30, 2008 at 5:05 PM, Laurie Harper [EMAIL PROTECTED] wrote: Richard Sayre wrote: Hi, I have a few questions regarding performance in Struts 2. First of all we are using 2.0.9. I am trying to get the source to fix the following memory leaks : https://issues.apache.org/struts/browse/WW-2167 but I can't find the 2.0.9 build. Can anyone point me to the source for that build? http://svn.apache.org/repos/asf/struts/struts2/tags/STRUTS_2_0_9/ We have several Struts 2 applications hosted on a Tomcat server. We have a copy of our Struts libraries in each of the applications WEB-INF folder. Is there a better way to have this set up to save memory? I know this is more of a tomcat question but I figured some one here might have some suggestions. As Giovanni said, you can put the struts jars (and dependencies) into a shared lib folder. You don't need to introduce Tomcat instancing to do this, though. I should also point out that this isn't a tested configuration, so you will want to test thoroughly. Also, when I run Firebug to check the loading time of my page it seems that alot of time is spent downloading Dojo scripts. I am only using the Ajax and the Tabbed Panel provided by dojo, nothing else. Is there a way to configure dojo to only use what is nessessary? I did see a post on this list a while ago that involved extracting the files and rewriting the dojo require file, is this still the best way to increase dojo performance? Yes; you can improve the Dojo multiple-http-requests issue by creating a custom Dojo build, which will bundle everything you use into dojo.js. You will then see only one request (for dojo.js) in place of the multiple requests you have now. See the Dojo documentation for how to create a custom profile/build, or see below. I was also getting a script is busy - cancel or continue in IE and Firefox. This was on a page that has a alot of HTML divs. I finally narrowed it down to some dojo that was running that seemed to be looping through every element on the page after it loaded. Does anyone have any insight into this behavior? Why is it needed? By default, Dojo scans the entire page looking for widgets to instantiate (i.e. looking for tags with a dojoType attribute). For pages with a lot of markup, that can be quite costly. There's a Dojo configuration switch to turn that off, but then you need to add code to bootstrap the widgets. Does the latest version 2.0.11.1 use a different version of dojo? Does it perform better? Would there be alot of code changes to change from 0.4 to the version that the current build uses? 2.0.11.1 doesn't offer much improvement, but 2.1.2 (beta) does. 2.1.2 comes with a custom Dojo build pre-baked and with widget scanning turned off (it also handles the widget bootstrapping for you). It's certainly more work to upgrade to 2.1.2 than 2.0.11.1 but, given your concerns, it is probably worth it. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 Performance
Doesn't s:head... have a parseContent attribute? Either way, you may just be able to replicate the s:head... generated code with your own. Dave --- On Mon, 6/9/08, Richard Sayre [EMAIL PROTECTED] wrote: From: Richard Sayre [EMAIL PROTECTED] Subject: Re: Struts 2 Performance To: Struts Users Mailing List user@struts.apache.org Date: Monday, June 9, 2008, 10:53 AM Thank you for the dojo info. I did a custom build for dojo using http://cwiki.apache.org/confluence/display/S2WIKI/Creating+a+custom+Dojo+profile+for+Struts+2.0.x and it reduced alot of requests I would like to turn off the page scan that dojo does and add the bootstrap code for the widgits my self. I'm not sure what to search for to find information on this. Can you point me to any articles or documentation? Thank you, Rich On Fri, May 30, 2008 at 5:05 PM, Laurie Harper [EMAIL PROTECTED] wrote: Richard Sayre wrote: Hi, I have a few questions regarding performance in Struts 2. First of all we are using 2.0.9. I am trying to get the source to fix the following memory leaks : https://issues.apache.org/struts/browse/WW-2167 but I can't find the 2.0.9 build. Can anyone point me to the source for that build? http://svn.apache.org/repos/asf/struts/struts2/tags/STRUTS_2_0_9/ We have several Struts 2 applications hosted on a Tomcat server. We have a copy of our Struts libraries in each of the applications WEB-INF folder. Is there a better way to have this set up to save memory? I know this is more of a tomcat question but I figured some one here might have some suggestions. As Giovanni said, you can put the struts jars (and dependencies) into a shared lib folder. You don't need to introduce Tomcat instancing to do this, though. I should also point out that this isn't a tested configuration, so you will want to test thoroughly. Also, when I run Firebug to check the loading time of my page it seems that alot of time is spent downloading Dojo scripts. I am only using the Ajax and the Tabbed Panel provided by dojo, nothing else. Is there a way to configure dojo to only use what is nessessary? I did see a post on this list a while ago that involved extracting the files and rewriting the dojo require file, is this still the best way to increase dojo performance? Yes; you can improve the Dojo multiple-http-requests issue by creating a custom Dojo build, which will bundle everything you use into dojo.js. You will then see only one request (for dojo.js) in place of the multiple requests you have now. See the Dojo documentation for how to create a custom profile/build, or see below. I was also getting a script is busy - cancel or continue in IE and Firefox. This was on a page that has a alot of HTML divs. I finally narrowed it down to some dojo that was running that seemed to be looping through every element on the page after it loaded. Does anyone have any insight into this behavior? Why is it needed? By default, Dojo scans the entire page looking for widgets to instantiate (i.e. looking for tags with a dojoType attribute). For pages with a lot of markup, that can be quite costly. There's a Dojo configuration switch to turn that off, but then you need to add code to bootstrap the widgets. Does the latest version 2.0.11.1 use a different version of dojo? Does it perform better? Would there be alot of code changes to change from 0.4 to the version that the current build uses? 2.0.11.1 doesn't offer much improvement, but 2.1.2 (beta) does. 2.1.2 comes with a custom Dojo build pre-baked and with widget scanning turned off (it also handles the widget bootstrapping for you). It's certainly more work to upgrade to 2.1.2 than 2.0.11.1 but, given your concerns, it is probably worth it. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 Performance
After some searching I found: http://lazutkin.com/blog/2007/feb/1/improving-performance/ Under ' Optimizing widget initialization' there is an explantion on what to set (parseWidgets) and how to create them in code. I realized I am using version 2.0.8 and me IDE says that parseContent is not a valid attribute for the s:head. What release was that attribure introduced? Thank you, Rich On Mon, Jun 9, 2008 at 11:49 AM, Dave Newton [EMAIL PROTECTED] wrote: Doesn't s:head... have a parseContent attribute? Either way, you may just be able to replicate the s:head... generated code with your own. Dave --- On Mon, 6/9/08, Richard Sayre [EMAIL PROTECTED] wrote: From: Richard Sayre [EMAIL PROTECTED] Subject: Re: Struts 2 Performance To: Struts Users Mailing List user@struts.apache.org Date: Monday, June 9, 2008, 10:53 AM Thank you for the dojo info. I did a custom build for dojo using http://cwiki.apache.org/confluence/display/S2WIKI/Creating+a+custom+Dojo+profile+for+Struts+2.0.x and it reduced alot of requests I would like to turn off the page scan that dojo does and add the bootstrap code for the widgits my self. I'm not sure what to search for to find information on this. Can you point me to any articles or documentation? Thank you, Rich On Fri, May 30, 2008 at 5:05 PM, Laurie Harper [EMAIL PROTECTED] wrote: Richard Sayre wrote: Hi, I have a few questions regarding performance in Struts 2. First of all we are using 2.0.9. I am trying to get the source to fix the following memory leaks : https://issues.apache.org/struts/browse/WW-2167 but I can't find the 2.0.9 build. Can anyone point me to the source for that build? http://svn.apache.org/repos/asf/struts/struts2/tags/STRUTS_2_0_9/ We have several Struts 2 applications hosted on a Tomcat server. We have a copy of our Struts libraries in each of the applications WEB-INF folder. Is there a better way to have this set up to save memory? I know this is more of a tomcat question but I figured some one here might have some suggestions. As Giovanni said, you can put the struts jars (and dependencies) into a shared lib folder. You don't need to introduce Tomcat instancing to do this, though. I should also point out that this isn't a tested configuration, so you will want to test thoroughly. Also, when I run Firebug to check the loading time of my page it seems that alot of time is spent downloading Dojo scripts. I am only using the Ajax and the Tabbed Panel provided by dojo, nothing else. Is there a way to configure dojo to only use what is nessessary? I did see a post on this list a while ago that involved extracting the files and rewriting the dojo require file, is this still the best way to increase dojo performance? Yes; you can improve the Dojo multiple-http-requests issue by creating a custom Dojo build, which will bundle everything you use into dojo.js. You will then see only one request (for dojo.js) in place of the multiple requests you have now. See the Dojo documentation for how to create a custom profile/build, or see below. I was also getting a script is busy - cancel or continue in IE and Firefox. This was on a page that has a alot of HTML divs. I finally narrowed it down to some dojo that was running that seemed to be looping through every element on the page after it loaded. Does anyone have any insight into this behavior? Why is it needed? By default, Dojo scans the entire page looking for widgets to instantiate (i.e. looking for tags with a dojoType attribute). For pages with a lot of markup, that can be quite costly. There's a Dojo configuration switch to turn that off, but then you need to add code to bootstrap the widgets. Does the latest version 2.0.11.1 use a different version of dojo? Does it perform better? Would there be alot of code changes to change from 0.4 to the version that the current build uses? 2.0.11.1 doesn't offer much improvement, but 2.1.2 (beta) does. 2.1.2 comes with a custom Dojo build pre-baked and with widget scanning turned off (it also handles the widget bootstrapping for you). It's certainly more work to upgrade to 2.1.2 than 2.0.11.1 but, given your concerns, it is probably worth it. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: Struts 2 Performance
Oh; that might be S2.1--sorry! Dave --- On Mon, 6/9/08, Richard Sayre [EMAIL PROTECTED] wrote: From: Richard Sayre [EMAIL PROTECTED] Subject: Re: Struts 2 Performance To: Struts Users Mailing List user@struts.apache.org, [EMAIL PROTECTED] Date: Monday, June 9, 2008, 12:09 PM After some searching I found: http://lazutkin.com/blog/2007/feb/1/improving-performance/ Under ' Optimizing widget initialization' there is an explantion on what to set (parseWidgets) and how to create them in code. I realized I am using version 2.0.8 and me IDE says that parseContent is not a valid attribute for the s:head. What release was that attribure introduced? Thank you, Rich On Mon, Jun 9, 2008 at 11:49 AM, Dave Newton [EMAIL PROTECTED] wrote: Doesn't s:head... have a parseContent attribute? Either way, you may just be able to replicate the s:head... generated code with your own. Dave --- On Mon, 6/9/08, Richard Sayre [EMAIL PROTECTED] wrote: From: Richard Sayre [EMAIL PROTECTED] Subject: Re: Struts 2 Performance To: Struts Users Mailing List user@struts.apache.org Date: Monday, June 9, 2008, 10:53 AM Thank you for the dojo info. I did a custom build for dojo using http://cwiki.apache.org/confluence/display/S2WIKI/Creating+a+custom+Dojo+profile+for+Struts+2.0.x and it reduced alot of requests I would like to turn off the page scan that dojo does and add the bootstrap code for the widgits my self. I'm not sure what to search for to find information on this. Can you point me to any articles or documentation? Thank you, Rich On Fri, May 30, 2008 at 5:05 PM, Laurie Harper [EMAIL PROTECTED] wrote: Richard Sayre wrote: Hi, I have a few questions regarding performance in Struts 2. First of all we are using 2.0.9. I am trying to get the source to fix the following memory leaks : https://issues.apache.org/struts/browse/WW-2167 but I can't find the 2.0.9 build. Can anyone point me to the source for that build? http://svn.apache.org/repos/asf/struts/struts2/tags/STRUTS_2_0_9/ We have several Struts 2 applications hosted on a Tomcat server. We have a copy of our Struts libraries in each of the applications WEB-INF folder. Is there a better way to have this set up to save memory? I know this is more of a tomcat question but I figured some one here might have some suggestions. As Giovanni said, you can put the struts jars (and dependencies) into a shared lib folder. You don't need to introduce Tomcat instancing to do this, though. I should also point out that this isn't a tested configuration, so you will want to test thoroughly. Also, when I run Firebug to check the loading time of my page it seems that alot of time is spent downloading Dojo scripts. I am only using the Ajax and the Tabbed Panel provided by dojo, nothing else. Is there a way to configure dojo to only use what is nessessary? I did see a post on this list a while ago that involved extracting the files and rewriting the dojo require file, is this still the best way to increase dojo performance? Yes; you can improve the Dojo multiple-http-requests issue by creating a custom Dojo build, which will bundle everything you use into dojo.js. You will then see only one request (for dojo.js) in place of the multiple requests you have now. See the Dojo documentation for how to create a custom profile/build, or see below. I was also getting a script is busy - cancel or continue in IE and Firefox. This was on a page that has a alot of HTML divs. I finally narrowed it down to some dojo that was running that seemed to be looping through every element on the page after it loaded. Does anyone have any insight into this behavior? Why is it needed? By default, Dojo scans the entire page looking for widgets to instantiate (i.e. looking for tags with a dojoType attribute). For pages with a lot of markup, that can be quite costly. There's a Dojo configuration switch to turn that off, but then you need to add code to bootstrap the widgets. Does the latest version 2.0.11.1 use a different version of dojo? Does it perform better? Would there be alot of code changes to change from 0.4 to the version that the current build uses? 2.0.11.1 doesn't offer much improvement, but 2.1.2 (beta) does. 2.1.2 comes with a custom Dojo build pre-baked and with widget scanning turned off (it also handles the widget bootstrapping for you). It's certainly more work to upgrade to 2.1.2 than 2.0.11.1 but, given your concerns, it is probably worth it. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
I see it also includes Tiles 2.0.4.. that should also include the fix for the contentType of the response not set bug present in version 2.0.3 -- Robi Ted Husted wrote: For those of you following this thread, a test build for Struts 2.0.9 is available. Unless a problem is found, we expect to upgrade the quality to a GA release by tomorrow evening, once the distribution has had time to propagate through the mirroring network. Another quick-fix to the OGNL expression issue is to replace a prior version of XWork2 with XWork 2.0.4. * http://www.opensymphony.com/xwork/download.action -- Forwarded message -- From: Ted Husted [EMAIL PROTECTED] Date: Jul 23, 2007 4:31 PM Subject: Re: Struts 2.0.9 release (was Re: S2 security fix release planning (XWork 2.0.4 is out)) To: Struts Developers List [EMAIL PROTECTED] The test build of Struts 2.0.9 is available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-209.html Distribution: * http://people.apache.org/builds/struts/2.0.9/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.9/m2-staging-repository/ We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. PLEASE NOTE In the interest of time, I would like to declare a quality grade on Struts 2.0.9 AS SOON AS we have received three binding votes toward one of the grades, and NOT WAIT the usual 72 hours! If not voting GA, please also be specific as to your concerns, so that we can address any issues immediately! Remember, a vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as Beta, the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. As always, the act of voting carries certain obligations. A binding vote not only states an opinion, but means that the voter is agreeing to help do the work -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
2007/7/24, Roberto Nunnari [EMAIL PROTECTED]: I see it also includes Tiles 2.0.4.. that should also include the fix for the contentType of the response not set bug present in version 2.0.3 Yep! Confirmed :-) Antonio
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
For those of you following this thread, a test build for Struts 2.0.9 is available. Unless a problem is found, we expect to upgrade the quality to a GA release by tomorrow evening, once the distribution has had time to propagate through the mirroring network. Another quick-fix to the OGNL expression issue is to replace a prior version of XWork2 with XWork 2.0.4. * http://www.opensymphony.com/xwork/download.action -- Forwarded message -- From: Ted Husted [EMAIL PROTECTED] Date: Jul 23, 2007 4:31 PM Subject: Re: Struts 2.0.9 release (was Re: S2 security fix release planning (XWork 2.0.4 is out)) To: Struts Developers List [EMAIL PROTECTED] The test build of Struts 2.0.9 is available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-209.html Distribution: * http://people.apache.org/builds/struts/2.0.9/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.9/m2-staging-repository/ We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. PLEASE NOTE In the interest of time, I would like to declare a quality grade on Struts 2.0.9 AS SOON AS we have received three binding votes toward one of the grades, and NOT WAIT the usual 72 hours! If not voting GA, please also be specific as to your concerns, so that we can address any issues immediately! Remember, a vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as Beta, the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. As always, the act of voting carries certain obligations. A binding vote not only states an opinion, but means that the voter is agreeing to help do the work -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
I tried this too, and I can confirm that it does actually shut down the server. The return value of the method that the property tag references is evaluated for some reason, which makes the application vulnerable to OGNL injection attacks... this is a huge security problem. On 7/16/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: Maybe it's new just for me, but I found out one of the main reasons of the problem try to submit [EMAIL PROTECTED]@exit(0)} in the viewable property for example you submit a text, and it is displayed by s2's tags try and have fun ... this expression works and my server shuts down! the problem I mentioned is that when I say print property it executes it at first ... but it should not! I'm right, amn't I? why it executes the string value in my property? (it's not just a problem, it's a security risk, the users can hack s2 sites) (at least who may read this message will know that he can hack s2 sites and the simplest way is given above) that's why even when you do not use ognl expressions, it still works and it costs ... Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
RE: Struts 2 performance
Tried this in a webwork app which is internal and it has the same problem. Shut down the server. David Sullivan - [EMAIL PROTECTED] Senior Java Developer ITSA - Insolvency and Trustee Services Australia (w) 6270 3436 (m) 0402 309 488 -Original Message- From: Toni Lyytikäinen [mailto:[EMAIL PROTECTED] Sent: Monday, 16 July 2007 4:10 PM To: Struts Users Mailing List Subject: Re: Struts 2 performance I tried this too, and I can confirm that it does actually shut down the server. The return value of the method that the property tag references is evaluated for some reason, which makes the application vulnerable to OGNL injection attacks... this is a huge security problem. On 7/16/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: Maybe it's new just for me, but I found out one of the main reasons of the problem try to submit [EMAIL PROTECTED]@exit(0)} in the viewable property for example you submit a text, and it is displayed by s2's tags try and have fun ... this expression works and my server shuts down! the problem I mentioned is that when I say print property it executes it at first ... but it should not! I'm right, amn't I? why it executes the string value in my property? (it's not just a problem, it's a security risk, the users can hack s2 sites) (at least who may read this message will know that he can hack s2 sites and the simplest way is given above) that's why even when you do not use ognl expressions, it still works and it costs ... Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
If your application is displaying user input without checking for malicious code, you have a problem whether Struts 2 evaluations ognl expressions or not.This is how the majority of Cross-Site Scripting (XSS) [1] attacks work, tricking the user into visiting a page that the attacker has placed JavaScript that steals their cookies. That said, the average Struts developer may not be aware of how OGNL is being used here, so we should do something to better protect the application. I'm taking this discussion over to the dev@ list. Don [1] http://en.wikipedia.org/wiki/Cross-site_scripting On 7/16/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: Maybe it's new just for me, but I found out one of the main reasons of the problem try to submit [EMAIL PROTECTED]@exit(0)} in the viewable property for example you submit a text, and it is displayed by s2's tags try and have fun ... this expression works and my server shuts down! the problem I mentioned is that when I say print property it executes it at first ... but it should not! I'm right, amn't I? why it executes the string value in my property? (it's not just a problem, it's a security risk, the users can hack s2 sites) (at least who may read this message will know that he can hack s2 sites and the simplest way is given above) that's why even when you do not use ognl expressions, it still works and it costs ... Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Is there a policy or person in the struts2, webwork or apache team with a PR role that's going to announce the vulnerability? I'm obliged to keep my clients informed and I'd rather point them to a factual article announced by the community than to a misinformed post that will undoubtedly soon appear on theserverside.com, slashdot or a vulnerability site. Don Brown wrote: If your application is displaying user input without checking for malicious code, you have a problem whether Struts 2 evaluations ognl expressions or not.This is how the majority of Cross-Site Scripting (XSS) [1] attacks work, tricking the user into visiting a page that the attacker has placed JavaScript that steals their cookies. That said, the average Struts developer may not be aware of how OGNL is being used here, so we should do something to better protect the application. I'm taking this discussion over to the dev@ list. Don [1] http://en.wikipedia.org/wiki/Cross-site_scripting On 7/16/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: Maybe it's new just for me, but I found out one of the main reasons of the problem try to submit [EMAIL PROTECTED]@exit(0)} in the viewable property for example you submit a text, and it is displayed by s2's tags try and have fun ... this expression works and my server shuts down! the problem I mentioned is that when I say print property it executes it at first ... but it should not! I'm right, amn't I? why it executes the string value in my property? (it's not just a problem, it's a security risk, the users can hack s2 sites) (at least who may read this message will know that he can hack s2 sites and the simplest way is given above) that's why even when you do not use ognl expressions, it still works and it costs ... Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
look here http://struts.apache.org/2.0.8/docs/property.html http://struts.apache.org/2.0.8/docs/text.html http://struts.apache.org/2.0.8/docs/if.html and in pages of other tags there you can find a column Evaluated and everywhere it has value true I guess that means that values are being evaluated! It's terrible ... It's not only a bottleneck, but also a security risk! Maybe there is a configuration parameter to disable that evaluation? Does someone have ideas where to find such configuration possibility? Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Should someone create a ticket in jira? I guess it is really a huge problem. Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
2007/7/16, Aram Mkhitaryan [EMAIL PROTECTED]: Should someone create a ticket in jira? Yep. https://issues.apache.org/struts/browse/WW-2030 Antonio
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
It's already known and a patch already exists. https://issues.apache.org/struts/browse/WW-2030 Don't know when a patched version will be released. Il giorno 16/lug/07, alle ore 10:29, Aram Mkhitaryan ha scritto: Should someone create a ticket in jira? I guess it is really a huge problem. Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
2007/7/16, Ing. Andrea Vettori [EMAIL PROTECTED]:
It's already known and a patch already exists.
Well, in fact the patch does not prevent execution of OGNL commands, but
disallow entering possible malicious code, i.e. expression like %{xxx} is
illegal: instead it should be evaluated as the string %{xxx}.
Antonio
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Sorry guys for spamming, but it is not clear what the patch exactly
resolves.
disallow entering possible malicious code, i.e. expression like %{xxx} is
illegal: instead it should be evaluated as the string %{xxx}.
what means the first is illegal, but should be evaluated as the string
could you please bring an example with s:property tag?
Best,
Aram
P.S. do you have a guide about how to apply patches?
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
The patch works the only problem is if you need to accept %{xxx} as
legal input from your users.
To apply the patch you need to download xwork sources, apply the
patch (with the patch command or manually if you don't have it since
there are few lines of code) and insert a couple of lines on
struts.xml. Recompile xwork and
use that jar instead of the jar distributed with struts.
Il giorno 16/lug/07, alle ore 10:44, Aram Mkhitaryan ha scritto:
Sorry guys for spamming, but it is not clear what the patch exactly
resolves.
disallow entering possible malicious code, i.e. expression like %
{xxx} is
illegal: instead it should be evaluated as the string %{xxx}.
what means the first is illegal, but should be evaluated as the string
could you please bring an example with s:property tag?
Best,
Aram
P.S. do you have a guide about how to apply patches?
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Actually that patch is not a solution, definitely.
The solution could be:
disable evaluation by default,
add a hint to enable evaluation.
for example
old---s:property value=%{amount} /
solution--- s:property value=eval/%{amount}
i suggest this solution since
s:property value=%{amount} /
and
s:property value=amount /
should output the same. am I wrong?
also because for the most of the cases just attribute values should be
printed and not evaluated the content
(note: the initial problem was the s2 performance)
Best,
Aram
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
2007/7/16, Aram Mkhitaryan [EMAIL PROTECTED]:
i suggest this solution since
s:property value=%{amount} /
and
s:property value=amount /
should output the same. am I wrong?
Definitely yes, I suggest you to learn the basics of OGNL :-)
And anyway, in JSP pages OGNL is ok: it is when user's inputs are used as
OGNL expressions that is wrong!.
Antonio
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Thanks for the response,
so if I type in my text input %{..System.exit(0);} it will not shut my
server down,
but what will happen?
will I get errors or just the text will not be evaluated?
Best,
Aram
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Take a look at the jira issue, it's something I suggested too. We
should disable by default evaluation of expressions when they are an
input from the user (i.e. parameters to an action) and enable by
default expression when specified as parameters to tags.
Il giorno 16/lug/07, alle ore 11:29, Aram Mkhitaryan ha scritto:
Actually that patch is not a solution, definitely.
The solution could be:
disable evaluation by default,
add a hint to enable evaluation.
for example
old---s:property value=%{amount} /
solution--- s:property value=eval/%{amount}
i suggest this solution since
s:property value=%{amount} /
and
s:property value=amount /
should output the same. am I wrong?
also because for the most of the cases just attribute values should be
printed and not evaluated the content
(note: the initial problem was the s2 performance)
Best,
Aram
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
The parameter is removed so it's like your input an empty string.
Il giorno 16/lug/07, alle ore 11:36, Aram Mkhitaryan ha scritto:
Thanks for the response,
so if I type in my text input %{..System.exit(0);} it will not shut my
server down,
but what will happen?
will I get errors or just the text will not be evaluated?
Best,
Aram
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROTECTED]
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
So the patch disables only evaluation of user submitted text,
but if I write expression in tags, that will work fine as before?
If this is true,
I think this is a good solution.
Sorry that I'm asking the same again, but this is the fastest way to know
the truth
so currently (without patches),
s:property value=propName / just prints the propName property, but
s:property value=%{propName} / evaluates the expression in %{} and if
propName=amout, it prints the amout property?
Best,
Aram
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Sorry that I'm asking the same again, but this is the fastest way
to know
the truth
so currently (without patches),
s:property value=propName / just prints the propName
property, but
s:property value=%{propName} / evaluates the expression in %{}
and if
propName=amout, it prints the amout property?
No, s:property value=%{propName}”/ should be equivalent to
s:property value=propName/.
I think You'll get the second behaviour with s:property value=%{%
{propName}}/
--
Ing. Andrea Vettori
Consulente per l'Information Technology
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
2007/7/16, Ing. Andrea Vettori [EMAIL PROTECTED]:
so currently (without patches),
s:property value=propName / just prints the propName
property, but
s:property value=%{propName} / evaluates the expression in %{}
and if
propName=amout, it prints the amout property?
No, s:property value=%{propName}/ should be equivalent to
s:property value=propName/.
Mmm I think that I (me, myself) have to learn the basics of OGNL :-)
Sorry
Antonio
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
I think we both have to find out, even better, to test which form works and does what ... Thanks, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
2007/7/16, Ing. Andrea Vettori [EMAIL PROTECTED]:
No, s:property value=%{propName}/ should be equivalent to
s:property value=propName/.
If it is true, then if you have a field named password and the user
types password then it is evaluated as %{password}, so you have an
infinite loop.
Andrea, this could be the cause of your memory leak. Or maybe I missed
something :-)
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
I'm glad to see so many people joining the discussion, but let's please take this to the dev list. There are a lot of Struts committers and contributors that don't read this user list. So please, no more messages on this thread for this list. Don On 7/16/07, Don Brown [EMAIL PROTECTED] wrote: If your application is displaying user input without checking for malicious code, you have a problem whether Struts 2 evaluations ognl expressions or not.This is how the majority of Cross-Site Scripting (XSS) [1] attacks work, tricking the user into visiting a page that the attacker has placed JavaScript that steals their cookies. That said, the average Struts developer may not be aware of how OGNL is being used here, so we should do something to better protect the application. I'm taking this discussion over to the dev@ list. Don [1] http://en.wikipedia.org/wiki/Cross-site_scripting On 7/16/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: Maybe it's new just for me, but I found out one of the main reasons of the problem try to submit [EMAIL PROTECTED]@exit(0)} in the viewable property for example you submit a text, and it is displayed by s2's tags try and have fun ... this expression works and my server shuts down! the problem I mentioned is that when I say print property it executes it at first ... but it should not! I'm right, amn't I? why it executes the string value in my property? (it's not just a problem, it's a security risk, the users can hack s2 sites) (at least who may read this message will know that he can hack s2 sites and the simplest way is given above) that's why even when you do not use ognl expressions, it still works and it costs ... Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
Don, could you please send the subject to continue the discussion in? Should we use [EMAIL PROTECTED] Thanks, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
I have replied in dev@ so please post over there. Thanks, Don On 7/16/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: Don, could you please send the subject to continue the discussion in? Should we use [EMAIL PROTECTED] Thanks, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
https://issues.apache.org/struts/browse/WW-2030 musachy On 7/16/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: look here http://struts.apache.org/2.0.8/docs/property.html http://struts.apache.org/2.0.8/docs/text.html http://struts.apache.org/2.0.8/docs/if.html and in pages of other tags there you can find a column Evaluated and everywhere it has value true I guess that means that values are being evaluated! It's terrible ... It's not only a bottleneck, but also a security risk! Maybe there is a configuration parameter to disable that evaluation? Does someone have ideas where to find such configuration possibility? Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Struts 2 performance
Maybe it's new just for me, but I found out one of the main reasons of the problem try to submit [EMAIL PROTECTED]@exit(0)} in the viewable property for example you submit a text, and it is displayed by s2's tags try and have fun ... this expression works and my server shuts down! the problem I mentioned is that when I say print property it executes it at first ... but it should not! I'm right, amn't I? why it executes the string value in my property? (it's not just a problem, it's a security risk, the users can hack s2 sites) (at least who may read this message will know that he can hack s2 sites and the simplest way is given above) that's why even when you do not use ognl expressions, it still works and it costs ... Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Yep, it should be relatively straightforward to do - there are of course some internal classloading considerations to make because of the bytecode enhancements... I plan on either updating documentation directly on the OGNL opensymphony site or creating via some other means today and will then make myself available to whomever is planning on doing this for webwork/struts2/xwork/etc.. It's the least I can do for all the help Patrick has given me... Sorry for not doing this sooner or replying in the thread earlier. Yes the OGNL enhancements really should remove OGNL as a bottleneck in your typical request. It's pure java code about 95% of the time. jesse Ted Husted wrote: As they say, the proof of the pudding is in the taste. The performance of Struts 2 is at least as good as WebWork 2, which powers a large number of excellent sites, including Atlassian Confluence and Jive Forums. Prior versions of Tapestry were also using OGNL, which seems to be one of the bottlenecks, and it too powered some excellent sites. Hopefully, James and other volunteers will be able to bring us up to date with OGNL 2.7, and maybe we will also see the night and day difference that Tapestry mentions. -Ted. -- View this message in context: http://www.nabble.com/Struts-2-performance-tf4053401.html#a11594315 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
On 7/13/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: Does someone know how to switch on the enhancement for ognl 2.7??? It's not a matter of throwing a switch. Some code would have to be rewritten in XWork 2 and Struts 2, which some people (James Holmes) are volunteering to do. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
* http://struts.apache.org/helping.html On 7/12/07, Don Brown [EMAIL PROTECTED] wrote: Ted wrote up a good doc somewhere on the website, but the summary is join the dev list, participate in discussions, file jira tickets with patches that include unit tests. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2 performance
Try using a some dummy beans for your MP3 test that return known data, that way you can get a good idea of the impact your database has on the response time. I suspect you'll find that your DB is causing a lot of the delay in the short ramp up test. -Original Message- From: Ing. Andrea Vettori [mailto:[EMAIL PROTECTED] Sent: 12 July 2007 11:30 To: Struts Users Mailing List Subject: Re: Struts 2 performance I've done some measurements with jmeter on my e-commerce site built on struts2 and ejb3. 1 user (testing) === Home page, http://www.elettrotop.com/ElettroTop/Home.action average response time : 63 msec MP3s list, http://www.elettrotop.com//ElettroTop/RicercaArticoliAlbero.action?path=AUDP ERMP3 average response time : 360 msec 100 users, ramp-up 200 seconds (average load) Home page, http://www.elettrotop.com/ElettroTop/Home.action average response time : 72 msec MP3s list, http://www.elettrotop.com//ElettroTop/RicercaArticoliAlbero.action?path=AUDP ERMP3 average response time : 378 msec 100 users, ramp-up 10 seconds (high-load) == Home page, http://www.elettrotop.com/ElettroTop/Home.action average response time : 59 msec throughput: 597 / minute MP3s list, http://www.elettrotop.com//ElettroTop/RicercaArticoliAlbero.action?path=AUDP ERMP3 average response time : 2,7 seconds throughput: 261 / minute The home page is moderately complex but it uses almost all cached data. The MP3s list loads from the db about 270 product records and shows the first 10. Most views component are produced using jsp custom tags so OGNL is used only on the back-end by struts itself and not by jsp pages. The site is using the simple theme. Any considerations on the numbers ? -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Yes i'm sure it's true. So the struts related performance seems not too bad... Il giorno 12/lug/07, alle ore 14:02, Al Sutton ha scritto: Try using a some dummy beans for your MP3 test that return known data, that way you can get a good idea of the impact your database has on the response time. I suspect you'll find that your DB is causing a lot of the delay in the short ramp up test. -Original Message- From: Ing. Andrea Vettori [mailto:[EMAIL PROTECTED] Sent: 12 July 2007 11:30 To: Struts Users Mailing List Subject: Re: Struts 2 performance I've done some measurements with jmeter on my e-commerce site built on struts2 and ejb3. 1 user (testing) === Home page, http://www.elettrotop.com/ElettroTop/Home.action average response time : 63 msec MP3s list, http://www.elettrotop.com//ElettroTop/RicercaArticoliAlbero.action? path=AUDP ERMP3 average response time : 360 msec 100 users, ramp-up 200 seconds (average load) Home page, http://www.elettrotop.com/ElettroTop/Home.action average response time : 72 msec MP3s list, http://www.elettrotop.com//ElettroTop/RicercaArticoliAlbero.action? path=AUDP ERMP3 average response time : 378 msec 100 users, ramp-up 10 seconds (high-load) == Home page, http://www.elettrotop.com/ElettroTop/Home.action average response time : 59 msec throughput: 597 / minute MP3s list, http://www.elettrotop.com//ElettroTop/RicercaArticoliAlbero.action? path=AUDP ERMP3 average response time : 2,7 seconds throughput: 261 / minute The home page is moderately complex but it uses almost all cached data. The MP3s list loads from the db about 270 product records and shows the first 10. Most views component are produced using jsp custom tags so OGNL is used only on the back-end by struts itself and not by jsp pages. The site is using the simple theme. Any considerations on the numbers ? -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Yes i'm sure it's true. So the struts related performance seems not too bad... compared to what? -- Guillaume Carré - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Yes i'm sure it's true. So the struts related performance seems not too bad... compared to what? Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
As they say, the proof of the pudding is in the taste. The performance of Struts 2 is at least as good as WebWork 2, which powers a large number of excellent sites, including Atlassian Confluence and Jive Forums. Prior versions of Tapestry were also using OGNL, which seems to be one of the bottlenecks, and it too powered some excellent sites. Hopefully, James and other volunteers will be able to bring us up to date with OGNL 2.7, and maybe we will also see the night and day difference that Tapestry mentions. -Ted. On 7/12/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Yes i'm sure it's true. So the struts related performance seems not too bad... compared to what? Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much time is consumed in your DB requests, how much time is consumed in your service layer, etc etc. Is it 90 users really active at the same time, meaning using 90 threads on the server?if it is, do you have at least 90 connections in your pool? or did you put think times in your tests? -- Guillaume Carré - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much time is consumed in your DB requests, how much time is consumed in your service layer, etc etc. Is it 90 users really active at the same time, meaning using 90 threads on the server?if it is, do you have at least 90 connections in your pool? or did you put think times in your tests? No think time... I have 250 threads but I have a limit of 50 connections on my pool. I'll try to raise the number of maximum connection to see if the MP3 list test gets better. However I think that struts alone is performing well for my app; don't know if it's because i'm using only few OGNL expressions on my jsp pages. -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much time is consumed in your DB requests, how much time is consumed in your service layer, etc etc. Is it 90 users really active at the same time, meaning using 90 threads on the server?if it is, do you have at least 90 connections in your pool? or did you put think times in your tests? No think time... I have 250 threads but I have a limit of 50 connections on my pool. I'll try to raise the number of maximum connection to see if the MP3 list test gets better. However I think that struts alone is performing well for my app; don't know if it's because i'm using only few OGNL expressions on my jsp pages. -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --No virus found in this incoming message. Checked by AVG Free Edition.Version: 7.5.476 / Virus Database: 269.10.4/897 - Release Date: 7/11/2007 9:57 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Perfect! This is an excellent start. I think both should be compiled with 1.6.0. That will immediately remove that element of difference between the two. James On Thu Jul 12 15:22 , 'Frank W. Zammetti' [EMAIL PROTECTED] sent: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much time is consumed in your DB requests, how much time is consumed in your service layer, etc etc. Is it 90 users really active at the same time, meaning using 90 threads on the server?if it is, do you have at least 90 connections in your pool? or did you put think times in your tests? No think time... I have 250 threads but I have a limit of 50 connections on my pool. I'll try to raise the number of maximum connection to see if the MP3 list test gets better. However I think that struts alone is performing well for my app; don't know if it's because i'm using only few OGNL expressions on my jsp pages. -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --No virus found in this incoming message. Checked by AVG Free Edition.Version: 7.5.476 / Virus Database: 269.10.4/897 - Release Date: 7/11/2007 9:57 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Are we targeting 1.6 now, or is the S2 target platform still 1.5? -T. On 7/12/07, James Holmes [EMAIL PROTECTED] wrote: Perfect! This is an excellent start. I think both should be compiled with 1.6.0. That will immediately remove that element of difference between the two. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
My only point was that the S1 and S2 apps should be compiled using the same version of Java. I didn't mean to imply any version that S2 should support. I guess in a perfect world the test should be compiled with 1.5 since that is what S2 supports. James On Thu Jul 12 15:34 , Ted Husted sent: Are we targeting 1.6 now, or is the S2 target platform still 1.5? -T. On 7/12/07, James Holmes [EMAIL PROTECTED] wrote: Perfect! This is an excellent start. I think both should be compiled with 1.6.0. That will immediately remove that element of difference between the two. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
The build scripts and full source are of course included, so by all means feel free to recompile and rerun... I'm getting into something else at the moment otherwise I'd do it right now because I'd be very interested in seeing if the results converge a bit (I wouldn't expect them to diverge, that's for sure!). Frank James Holmes wrote: My only point was that the S1 and S2 apps should be compiled using the same version of Java. I didn't mean to imply any version that S2 should support. I guess in a perfect world the test should be compiled with 1.5 since that is what S2 supports. James On Thu Jul 12 15:34 , Ted Husted sent: Are we targeting 1.6 now, or is the S2 target platform still 1.5? -T. On 7/12/07, James Holmes [EMAIL PROTECTED] wrote: Perfect! This is an excellent start. I think both should be compiled with 1.6.0. That will immediately remove that element of difference between the two. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Frank, would you care to give the same tests a shot with ognl 2.7 and javassist in the mix. Although none of this is purely scientific, at least evaluations on that regard give us some level of subjective information. The ognl 2.7 and javassist jar are available via the tapestry-4.2-libs download : http://tapestry.apache.org/download.html Frank W. Zammetti wrote: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much time is consumed in your DB requests, how much time is consumed in your service layer, etc etc. Is it 90 users really active at the same time, meaning using 90 threads on the server?if it is, do you have at least 90 connections in your pool? or did you put think times in your tests? No think time... I have 250 threads but I have a limit of 50 connections on my pool. I'll try to raise the number of maximum connection to see if the MP3 list test gets better. However I think that struts alone is performing well for my app; don't know if it's because i'm using only few OGNL expressions on my jsp pages. -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --No virus found in this incoming message. Checked by AVG Free Edition.Version: 7.5.476 / Virus Database: 269.10.4/897 - Release Date: 7/11/2007 9:57 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Struts-2-performance-tf4053401.html#a11568260 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
for my sake, i hope it's still 1.5. i'm not allowed to go near 1.6 because of some obscure bug in some oracle driver somewhere. Ted Husted wrote: Are we targeting 1.6 now, or is the S2 target platform still 1.5? -T. On 7/12/07, James Holmes [EMAIL PROTECTED] wrote: Perfect! This is an excellent start. I think both should be compiled with 1.6.0. That will immediately remove that element of difference between the two. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Struts-2-performance-tf4053401.html#a11568292 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Well, here's exactly why I hate benchmarking: it's never consistent! :) This time, everything compiled with JDK 1.6 (it's what I have installed along side 1.4.2) and all used 5000 samples (updated test plan to always do 5000 samples)... S1: 685 average, 142.3/sec throughput, 20.89 KB/sec So, an improvement there, maybe because of the JDK, maybe not. S2 w/OGNL 2.6: 1054 average, 87.3/sec throughput, 12.87 KB/sec That's better than the last run, but for no apparent reason! S2 W/OGNL 2.7: 1073 average, 85.8/sec throughput, 12.65 KB/sec Wuh?!? Ok, I think we can most likely dismiss the difference as within a statistical margin of difference, which means either (a) these tests are just flat-out flawed somehow, (b) the OGNL bump, at least as far as just a straight drop-in, makes no real difference, or (c) OGNL isn't being used to enough of an extent in this test to notice a difference (I'm frankly betting on that one). FYI, I've created JIRA ticket WW-2040... that way if others want to extend the apps, they can attach an updated version to the ticket so everyone can share. Frank cilquirm wrote: Frank, would you care to give the same tests a shot with ognl 2.7 and javassist in the mix. Although none of this is purely scientific, at least evaluations on that regard give us some level of subjective information. The ognl 2.7 and javassist jar are available via the tapestry-4.2-libs download : http://tapestry.apache.org/download.html Frank W. Zammetti wrote: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much time is consumed in your DB requests, how much time is consumed in your service layer, etc etc. Is it 90 users really active at the same time, meaning using 90 threads on the server?if it is, do you have at least 90 connections in your pool? or did you put think times in your tests? No think time... I have 250 threads but I have a limit of 50 connections on my pool. I'll try to raise the number of maximum connection to see if the MP3 list test gets better. However I think that struts alone is performing well for my app; don't know if it's because i'm using only few OGNL expressions
Re: Struts 2 performance
On 7/12/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: (b) the OGNL bump, at least as far asjust a straight drop-in, makes no real difference I don't think we really expected the drop-in to make a difference without making other adjustment to take advantage of the enhancements. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2 performance
We've only seen some initial high level benchmarks, and there isn't enough information yet to assert what is the source of the performance differences. This should be identified before trying things like a new version of OGNL. David -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 6:39 PM To: Struts Users Mailing List Subject: Re: Struts 2 performance I'm really happy to see this issue being addressed, but it is important to remember, framework performance wasn't (isn't?) a primary goal for WebWork 2, and now Struts 2. Specific decisions were made to favor developer productivity and flexibility over performance such as a template engine-based, theme-capable tag rendering and rich expression language usage throughout. Still, it is possible to do things like reimplement the tags using a pure Java template engine, which gives 2-3x performance gains, but in the end, you are left with very inflexible tags that are a pain to extend and customize. Of course, if you just use the simple theme, then this idea might still be attractive. Finally, it is worth repeating that in a typical web application, the framework should be such a small part of processing, but if it is not, those are the types of issues I'd like to really address. Don On 7/13/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: Well, here's exactly why I hate benchmarking: it's never consistent! :) This time, everything compiled with JDK 1.6 (it's what I have installed along side 1.4.2) and all used 5000 samples (updated test plan to always do 5000 samples)... S1: 685 average, 142.3/sec throughput, 20.89 KB/sec So, an improvement there, maybe because of the JDK, maybe not. S2 w/OGNL 2.6: 1054 average, 87.3/sec throughput, 12.87 KB/sec That's better than the last run, but for no apparent reason! S2 W/OGNL 2.7: 1073 average, 85.8/sec throughput, 12.65 KB/sec Wuh?!? Ok, I think we can most likely dismiss the difference as within a statistical margin of difference, which means either (a) these tests are just flat-out flawed somehow, (b) the OGNL bump, at least as far as just a straight drop-in, makes no real difference, or (c) OGNL isn't being used to enough of an extent in this test to notice a difference (I'm frankly betting on that one). FYI, I've created JIRA ticket WW-2040... that way if others want to extend the apps, they can attach an updated version to the ticket so everyone can share. Frank cilquirm wrote: Frank, would you care to give the same tests a shot with ognl 2.7 and javassist in the mix. Although none of this is purely scientific, at least evaluations on that regard give us some level of subjective information. The ognl 2.7 and javassist jar are available via the tapestry-4.2-libs download : http://tapestry.apache.org/download.html Frank W. Zammetti wrote: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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
Re: Struts 2 performance
I'm really happy to see this issue being addressed, but it is important to remember, framework performance wasn't (isn't?) a primary goal for WebWork 2, and now Struts 2. Specific decisions were made to favor developer productivity and flexibility over performance such as a template engine-based, theme-capable tag rendering and rich expression language usage throughout. Still, it is possible to do things like reimplement the tags using a pure Java template engine, which gives 2-3x performance gains, but in the end, you are left with very inflexible tags that are a pain to extend and customize. Of course, if you just use the simple theme, then this idea might still be attractive. Finally, it is worth repeating that in a typical web application, the framework should be such a small part of processing, but if it is not, those are the types of issues I'd like to really address. Don On 7/13/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: Well, here's exactly why I hate benchmarking: it's never consistent! :) This time, everything compiled with JDK 1.6 (it's what I have installed along side 1.4.2) and all used 5000 samples (updated test plan to always do 5000 samples)... S1: 685 average, 142.3/sec throughput, 20.89 KB/sec So, an improvement there, maybe because of the JDK, maybe not. S2 w/OGNL 2.6: 1054 average, 87.3/sec throughput, 12.87 KB/sec That's better than the last run, but for no apparent reason! S2 W/OGNL 2.7: 1073 average, 85.8/sec throughput, 12.65 KB/sec Wuh?!? Ok, I think we can most likely dismiss the difference as within a statistical margin of difference, which means either (a) these tests are just flat-out flawed somehow, (b) the OGNL bump, at least as far as just a straight drop-in, makes no real difference, or (c) OGNL isn't being used to enough of an extent in this test to notice a difference (I'm frankly betting on that one). FYI, I've created JIRA ticket WW-2040... that way if others want to extend the apps, they can attach an updated version to the ticket so everyone can share. Frank cilquirm wrote: Frank, would you care to give the same tests a shot with ognl 2.7 and javassist in the mix. Although none of this is purely scientific, at least evaluations on that regard give us some level of subjective information. The ognl 2.7 and javassist jar are available via the tapestry-4.2-libs download : http://tapestry.apache.org/download.html Frank W. Zammetti wrote: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the
Re: Struts 2 performance
Ted Husted wrote: On 7/12/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: (b) the OGNL bump, at least as far asjust a straight drop-in, makes no real difference I don't think we really expected the drop-in to make a difference without making other adjustment to take advantage of the enhancements. Yeah, that's the understanding I had from all the comments, just thought it was worth saying in case anyone did have that expectation. -T. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Frank, There should not be a noticable difference with OGNL yet. The performance improvements in OGNL 2.7 require expressions to be compiled before being executed. The current S2 code does not do this yet so it cannot realize the performance gains yet. Sent via BlackBerry. -Original Message- From: Frank W. Zammetti [EMAIL PROTECTED] Date: Thu, 12 Jul 2007 17:10:17 To:Struts Users Mailing List user@struts.apache.org Subject: Re: Struts 2 performance Well, here's exactly why I hate benchmarking: it's never consistent! :) This time, everything compiled with JDK 1.6 (it's what I have installed along side 1.4.2) and all used 5000 samples (updated test plan to always do 5000 samples)... S1: 685 average, 142.3/sec throughput, 20.89 KB/sec So, an improvement there, maybe because of the JDK, maybe not. S2 w/OGNL 2.6: 1054 average, 87.3/sec throughput, 12.87 KB/sec That's better than the last run, but for no apparent reason! S2 W/OGNL 2.7: 1073 average, 85.8/sec throughput, 12.65 KB/sec Wuh?!? Ok, I think we can most likely dismiss the difference as within a statistical margin of difference, which means either (a) these tests are just flat-out flawed somehow, (b) the OGNL bump, at least as far as just a straight drop-in, makes no real difference, or (c) OGNL isn't being used to enough of an extent in this test to notice a difference (I'm frankly betting on that one). FYI, I've created JIRA ticket WW-2040... that way if others want to extend the apps, they can attach an updated version to the ticket so everyone can share. Frank cilquirm wrote: Frank, would you care to give the same tests a shot with ognl 2.7 and javassist in the mix. Although none of this is purely scientific, at least evaluations on that regard give us some level of subjective information. The ognl 2.7 and javassist jar are available via the tapestry-4.2-libs download : http://tapestry.apache.org/download.html Frank W. Zammetti wrote: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much time is consumed in your DB requests, how much time is consumed
Re: Struts 2 performance
I'm still betting OGNL isn't hit in any significant way in this test anyhow... in fact, is it used at all? I'm not even certain... I assume this line does: s:property value=greeting / But maybe I'm wrong? Like I said, even if it is, if *that* made any sort of real difference in the numbers, I'd be flat-out shocked. Frank James Holmes wrote: Frank, There should not be a noticable difference with OGNL yet. The performance improvements in OGNL 2.7 require expressions to be compiled before being executed. The current S2 code does not do this yet so it cannot realize the performance gains yet. Sent via BlackBerry. -Original Message- From: Frank W. Zammetti [EMAIL PROTECTED] Date: Thu, 12 Jul 2007 17:10:17 To:Struts Users Mailing List user@struts.apache.org Subject: Re: Struts 2 performance Well, here's exactly why I hate benchmarking: it's never consistent! :) This time, everything compiled with JDK 1.6 (it's what I have installed along side 1.4.2) and all used 5000 samples (updated test plan to always do 5000 samples)... S1: 685 average, 142.3/sec throughput, 20.89 KB/sec So, an improvement there, maybe because of the JDK, maybe not. S2 w/OGNL 2.6: 1054 average, 87.3/sec throughput, 12.87 KB/sec That's better than the last run, but for no apparent reason! S2 W/OGNL 2.7: 1073 average, 85.8/sec throughput, 12.65 KB/sec Wuh?!? Ok, I think we can most likely dismiss the difference as within a statistical margin of difference, which means either (a) these tests are just flat-out flawed somehow, (b) the OGNL bump, at least as far as just a straight drop-in, makes no real difference, or (c) OGNL isn't being used to enough of an extent in this test to notice a difference (I'm frankly betting on that one). FYI, I've created JIRA ticket WW-2040... that way if others want to extend the apps, they can attach an updated version to the ticket so everyone can share. Frank cilquirm wrote: Frank, would you care to give the same tests a shot with ognl 2.7 and javassist in the mix. Although none of this is purely scientific, at least evaluations on that regard give us some level of subjective information. The ognl 2.7 and javassist jar are available via the tapestry-4.2-libs download : http://tapestry.apache.org/download.html Frank W. Zammetti wrote: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users
Re: Struts 2 performance
Doesn't xwork cache the expressions compiled? musachy On 7/12/07, James Holmes [EMAIL PROTECTED] wrote: Frank, There should not be a noticable difference with OGNL yet. The performance improvements in OGNL 2.7 require expressions to be compiled before being executed. The current S2 code does not do this yet so it cannot realize the performance gains yet. Sent via BlackBerry. -Original Message- From: Frank W. Zammetti [EMAIL PROTECTED] Date: Thu, 12 Jul 2007 17:10:17 To:Struts Users Mailing List user@struts.apache.org Subject: Re: Struts 2 performance Well, here's exactly why I hate benchmarking: it's never consistent! :) This time, everything compiled with JDK 1.6 (it's what I have installed along side 1.4.2) and all used 5000 samples (updated test plan to always do 5000 samples)... S1: 685 average, 142.3/sec throughput, 20.89 KB/sec So, an improvement there, maybe because of the JDK, maybe not. S2 w/OGNL 2.6: 1054 average, 87.3/sec throughput, 12.87 KB/sec That's better than the last run, but for no apparent reason! S2 W/OGNL 2.7: 1073 average, 85.8/sec throughput, 12.65 KB/sec Wuh?!? Ok, I think we can most likely dismiss the difference as within a statistical margin of difference, which means either (a) these tests are just flat-out flawed somehow, (b) the OGNL bump, at least as far as just a straight drop-in, makes no real difference, or (c) OGNL isn't being used to enough of an extent in this test to notice a difference (I'm frankly betting on that one). FYI, I've created JIRA ticket WW-2040... that way if others want to extend the apps, they can attach an updated version to the ticket so everyone can share. Frank cilquirm wrote: Frank, would you care to give the same tests a shot with ognl 2.7 and javassist in the mix. Although none of this is purely scientific, at least evaluations on that regard give us some level of subjective information. The ognl 2.7 and javassist jar are available via the tapestry-4.2-libs download : http://tapestry.apache.org/download.html Frank W. Zammetti wrote: Dunno if this might help, but: http://www.omnytex.com/struts_benchmarking.zip In it you'll find two applications, one for S1 (1.3.8) and one for S2 (2.0.8)... they are both (I think!) pretty much equivalent, and about as simplistic as you can get. Also included is a JMeter test plan to run against them (just disable one or the other thread group, wouldn't want to test them both at the same time!). Just ran a quick-and-dirty comparison of the two using the test plan... I ran 100 users with no ramp-up... local Tomcat instance (6.0.13)... the one difference is that the S1 version was compiled with JDK 1.4.2, and the S2 version with 1.6.0, so there's at least one potentially big variance right up front... here's what I saw: S1 results: 4256 samples, 913 average, 108.6/sec throughput, 16.01 KB/sec S2 results: 4165 samples, 1974 average, 50.0/sec throughput, 7.38 KB/sec I'm not claiming this to be the perfect test, nor do I believe there's not some flaws in there (benchmarking is always a tough thing to get quite right, especially trying to do a comparison like this)... but, unless someone can point out some obvious mistakes I made, the numbers don't lie: S2 *looks*, *on the surface* at least, to be inherently twice as slow as S1. I'm not trying to make any sensational claims here, and again, I may have totally blown it in the first place (I did throw this together in about 30 minutes after all), but if we can use this as a basis going forward, maybe build it up as a more expansive, realistic and solid benchmarking suite, then it's all good in the end. Anyway, it's there, if anyone's interested. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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! Ing. Andrea Vettori wrote: Il giorno 12/lug/07, alle ore 16:31, Guillaume Carré ha scritto: 2007/7/12, Ing. Andrea Vettori [EMAIL PROTECTED]: Compared to nothing... they are pure numbers. They are simply just good enought (to me). If we don't have this in mind we should use assember for everything :) what I meant was: maybe it could be a good idea to redevelop your screens with, say struts 1 for example, and compare the results I can't do that... simply don't have the time... :) In the high load test, after 10 seconds you have about 90 users (the other 10 should have finished). Having a response time of 2,5 seconds for a db search and result display under such load seems very good to me. Don't you ? it depends :-) 2.5s doesn't say much to me, I would need to know how much
Re: Struts 2 performance
One more point for the test applications, try do not use complicated pages with db calls and stuff like that use simple pages where you have lots of ognl expressions (as there is ticket in jira where it is noticed that profiler showed that the bottleneck is in ognl expressions) Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
there are some new results, when setting the global theme to the simple one, my S2 test application becomes 20 times faster, but still it is 3 times slower then S1 There should not be a noticable difference with OGNL yet. The performance improvements in OGNL 2.7 require expressions to be compiled before being executed. The current S2 code does not do this yet so it cannot realize the performance gains yet. what does mean compiled before being executed? S2 should do this? Does someone know how to switch on the enhancement for ognl 2.7??? Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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?
Re: Struts 2 performance
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
On 7/11/07, Aram Mkhitaryan [EMAIL PROTECTED] 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: +374 91 518456 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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
Re: Struts 2 performance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
On 7/11/07, Aram Mkhitaryan [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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 [EMAIL PROTECTED] wrote: On 7/11/07, Aram Mkhitaryan [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Struts 2 performance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
2007/7/11, Musachy Barroso [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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é' [EMAIL PROTECTED] sent: 2007/7/11, Musachy Barroso [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
On 7/11/07, Guillaume Carré [EMAIL PROTECTED] wrote: 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? I don't know, I'll give it a try. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
hmm, if someone would specify a valid test-case or test-app, i'd volunteer to implement it in both s1 and s2 and measure the points where the performance is lost exactly. /2cents Leon On 7/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] wrote: On 7/11/07, Aram Mkhitaryan [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
I think that the s2 app should have more than one version depending on the used template. I think the test app should have - listing rows from a database - displaying row details These should be the most used pattern used on many sites and it can be also a part of a CRUD application. Add an input form and I think you have a good starting point to make some benchmarks. I think the backend datastore should be in-memory and pre-loaded before making any measurement. Il giorno 11/lug/07, alle ore 16:21, Leon Rosenberg ha scritto: hmm, if someone would specify a valid test-case or test-app, i'd volunteer to implement it in both s1 and s2 and measure the points where the performance is lost exactly. /2cents Leon On 7/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] wrote: On 7/11/07, Aram Mkhitaryan [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ing. Andrea Vettori Consulente per l'Information Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
On 7/11/07, Leon Rosenberg [EMAIL PROTECTED] wrote: if someone would specify a valid test-case or test-app, i'd volunteer to implement it in both s1 and s2 and measure the points where the performance is lost exactly. There's a WW application attached to this ticket that might be a likely starting point. * https://issues.apache.org/struts/browse/WW-1560 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Struts tests pass with OGNL 2.7 musachy On 7/11/07, James Holmes [EMAIL PROTECTED] wrote: 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é' [EMAIL PROTECTED] sent: 2007/7/11, Musachy Barroso [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Struts 2 performance
On 7/11/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: 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 haven't used it personally, but there's the Eclipse TPTP project that works with the eclipse web tools platform via a seperately downloaded plugin (tptp-wtp). http://www.eclipse.org/tptp/ HTH, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
I have dropped 2.7 into a WW app which has been live for the past week with zero (new) errors. However, as has been stated, it needs to be reworked to get the speed improvments. - Original message - From: Musachy Barroso [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Date: Wed, 11 Jul 2007 15:03:51 -0400 Subject: Re: Struts 2 performance Struts tests pass with OGNL 2.7 musachy On 7/11/07, James Holmes [EMAIL PROTECTED] wrote: 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é' [EMAIL PROTECTED] sent: 2007/7/11, Musachy Barroso [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
If we need to test the Struts2's real performance we should not use database calls and stuff like that. The code should be as simple as possible, for example, as it was already suggested, we may use static data (a big enough list with beans that have at least 5 properties). We may include some logical part, for example, exclude beans with odd indexes to add a little functionality (we should notice that the bottleneck is in frontend/jsp/ognl side not in backend/actions side). There were a question about how to test and how to measure the performance ... jmeter is a good choice. You may start jmeter with at least, for example, 20 concurrent clients, and set timeout to, for example, 1s. The more tests pass the better the performance is. Then you can decrease timeout and increase clients count. Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
BTW, the idea about participation in contributing to this part is good. I would love to solve this performance problem. Does someone know how we can become a contributor of struts2? Is there a standard procedure, or we just can solve ourselves and send the result code? Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
Ted wrote up a good doc somewhere on the website, but the summary is join the dev list, participate in discussions, file jira tickets with patches that include unit tests. Don On 7/12/07, Aram Mkhitaryan [EMAIL PROTECTED] wrote: BTW, the idea about participation in contributing to this part is good. I would love to solve this performance problem. Does someone know how we can become a contributor of struts2? Is there a standard procedure, or we just can solve ourselves and send the result code? Best, Aram Aram Mkhitaryan 52, 25 Lvovyan, Yerevan 375000, Armenia Mobile: +374 91 518456 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
On 7/9/07, climbingrose [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Cuong Hoang
Re: Struts 2 performance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 performance
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Cuong Hoang
Re: Struts 2 performance
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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
