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