Re: OGNL performance detrimental to Struts 2
When I see OGNL classes in exceptions stack trace, I believe it is not as fast as 2+2. But I have never thought to replace ww:property tags with %= % scriplets. ww:property performance is enough for me, for now. WebWork form tags could be really slow. After I have moved templates out of webwork.jar to WEB-INF/template directory, performance improved drastically. Before that my application spent about 90% of CPU time in Freemarker.loadTemplate method. I believe that the test which caused this thread was using form tags. What could be done more to improve performance of form tags? Several months ago I did the following evaluation for my project. Since I was not going to put too much form tags on one page, I had no concerns about its performance impact. But I had a lot of design elements which were used over all pages and could appear many time on one page. I had thought about solution how to make such design elements reusable: 1. JSP include via include directive 2. JSP include vie jsp:include JSP tag 3. using WebWork component tag with own template 4. own WebWork tag with JSP template 5. own WebWork tag with Freemarker template 6. own WebWork tag with Velocity template 7. JSP tag without template (HTML printed directly from Java code out) Test page was create to test performance of these different approaches. The page printed the same component 50 times and printed the time required to render the components (50 components). The component itself represented link to user profile: It was tested on Tomcat 5.5, Windows XP professional, WebWork 2.2.4 Test results: Test Time (ms) to render 50 components 1. include directive 47 2. jsp:include 94 3. ww:component tag with jsp template 109 4. b:jspSimpleProfile tag 79 5. b:ftlSimpleProfile tag 46 6. b:vmSimpleProfile tag 32 7. b:lightProfile tag 0 My conclusions were: - JSP include directive suites for the cases when the included page doesn't contain much logic and is not used often on a page. - jsp:include - better not to use it. Instead of it use include directive - it is faster. If you need to pass additional parameters to the included page, you can put them into value stack. - avoid using ww:component tag. Use JSP include directive instead - it is faster. - if you have much or complex logic and you need complex rendering, create your own UI tag with separated template file - the same way WebWorks does it. Extend your Tag and Component classes from WebWork classes. Use Freemarker template, since it is faster than JSP. Velocity teplates are even faster, but it is better to use Freemarker templates since all WebWork components using it and you can get working examples or event reusable template parts. - if you have simple view but with complex logic or if it used very often - write your own JSP tag with template hardcoded in Java code. Thus I think replacing WebWork/Struts2 form tags by simple JSP tags with HTML hardcoded in Java code will boost performance for tests where form tags are used extensively. But if you would like to have form tags as flexible as they are now, the current implementation is optimal. Their performance is comparable with JSP include directive. I hope that form tags with externalized templates will stay in Struts 2.x :-). You could have two kind of form tags: simple one with hardcoded in Java template and one with Freemarker template. To avoid such long threads in future, probably it makes sense to add some performance benchmark page in struts examples distribution. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135444#135444 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] [VOTE] Struts 2.0.7 Quality
+1 (GA) too Herrera Nate Drake wrote: +1 (GA) On 3/23/07, Ted Husted [EMAIL PROTECTED] wrote: There's not an actual drop-dead date. Like merit, quality votes never expire. The 72-hour clause just means that if we had 3 +1s by then, and nothing seemed awry, we might go ahead and announce it. Hey, elsewhere, I've been known to cast positive quality votes even weeks after the announcement, just as a matter of record. :) Even after we announce a quality grade, the grade is still subject to actual experience. If a serious issue were discovered later, we could change our votes and downgrade the quality, if appropriate. Likewise, we can vote a release alpha or beta, announce it, let others try it, and then upgrade the quality based on positive experience. An ASF release vote is not a political statement or a marketing vehicle. It's our best, ongoing assessment of whether the bits are ready to be deployed by the general public. -Ted. On 3/23/07, Philip Luppens [EMAIL PROTECTED] wrote: Same here .. it would be easier if we could extend the period until after the weekend, making it easier for those not able to work on S2 during the day/week. Phil On 3/23/07, James Mitchell [EMAIL PROTECTED] wrote: Unfortunately, I got pulled away on a critical issue and was not able to run through this as fully as I would have liked. So +0 from me, unless I can find more time before the 72 hours runs out. -- James Mitchell The Ruby Roundup http://www.rubyroundup.com/ On Mar 21, 2007, at 4:59 PM, Ted Husted wrote: The Struts 2.0.7 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-207.html Distribution: * http://people.apache.org/builds/struts/2.0.7/ The Maven 2 staging repository is not yet available, but when it is, it will be in the usual location: * http://people.apache.org/builds/struts/2.0.7/m2-staging- repository/ 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. The vote will remain open for at least 72 hours, longer upon request. 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] -- View this message in context: http://www.nabble.com/-S2---VOTE--Struts-2.0.7-Quality-tf3443816.html#a9649366 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
To avoid such long threads in future, probably it makes sense to add some performance benchmark page in struts examples distribution. Would it be possible to contribute the test page you've already started? We have a ticket open. * https://issues.apache.org/struts/browse/WW-1560 I'm also attaching your kind response to the Performance Tuning page as a comment, if that's all right. -Ted. On 3/24/07, Vlad [EMAIL PROTECTED] wrote: When I see OGNL classes in exceptions stack trace, I believe it is not as fast as 2+2. But I have never thought to replace ww:property tags with %= % scriplets. ww:property performance is enough for me, for now. WebWork form tags could be really slow. After I have moved templates out of webwork.jar to WEB-INF/template directory, performance improved drastically. Before that my application spent about 90% of CPU time in Freemarker.loadTemplate method. I believe that the test which caused this thread was using form tags. What could be done more to improve performance of form tags? Several months ago I did the following evaluation for my project. Since I was not going to put too much form tags on one page, I had no concerns about its performance impact. But I had a lot of design elements which were used over all pages and could appear many time on one page. I had thought about solution how to make such design elements reusable: 1. JSP include via include directive 2. JSP include vie jsp:include JSP tag 3. using WebWork component tag with own template 4. own WebWork tag with JSP template 5. own WebWork tag with Freemarker template 6. own WebWork tag with Velocity template 7. JSP tag without template (HTML printed directly from Java code out) Test page was create to test performance of these different approaches. The page printed the same component 50 times and printed the time required to render the components (50 components). The component itself represented link to user profile: It was tested on Tomcat 5.5, Windows XP professional, WebWork 2.2.4 Test results: Test Time (ms) to render 50 components 1. include directive 47 2. jsp:include 94 3. ww:component tag with jsp template 109 4. b:jspSimpleProfile tag 79 5. b:ftlSimpleProfile tag 46 6. b:vmSimpleProfile tag 32 7. b:lightProfile tag 0 My conclusions were: - JSP include directive suites for the cases when the included page doesn't contain much logic and is not used often on a page. - jsp:include - better not to use it. Instead of it use include directive - it is faster. If you need to pass additional parameters to the included page, you can put them into value stack. - avoid using ww:component tag. Use JSP include directive instead - it is faster. - if you have much or complex logic and you need complex rendering, create your own UI tag with separated template file - the same way WebWorks does it. Extend your Tag and Component classes from WebWork classes. Use Freemarker template, since it is faster than JSP. Velocity teplates are even faster, but it is better to use Freemarker templates since all WebWork components using it and you can get working examples or event reusable template parts. - if you have simple view but with complex logic or if it used very often - write your own JSP tag with template hardcoded in Java code. Thus I think replacing WebWork/Struts2 form tags by simple JSP tags with HTML hardcoded in Java code will boost performance for tests where form tags are used extensively. But if you would like to have form tags as flexible as they are now, the current implementation is optimal. Their performance is comparable with JSP include directive. I hope that form tags with externalized templates will stay in Struts 2.x :-). You could have two kind of form tags: simple one with hardcoded in Java template and one with Freemarker template. To avoid such long threads in future, probably it makes sense to add some performance benchmark page in struts examples distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jar to their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jar to their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - 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: OGNL performance detrimental to Struts 2
Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - 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: XWork build failing
Is it just me or is surefire not a bit strange on the xwork project? Could you try this: mvn clean mvn surefire-report:report And then look in target/site/surefire-report.html. Then click on the first test - ActionContextTest. It should have only 8 tests. but the list is much bigger on my report, probably about 60-80 tests. It looks like it's tests from other unit tests classes got mixed in. It's also wrong in the TEST-.xml files in the target/surefire-reports folder. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=72225messageID=135519#135519 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - 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: OGNL performance detrimental to Struts 2
We could enable the cache when devMode is false. musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - 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] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: XWork build failing
Damm surefire seems to be a bit buggy. Just browsed it's JIRA. Created a minor bug: http://jira.codehaus.org/browse/SUREFIRE-312 - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=72225messageID=135529#135529 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
As I believe the Ajax/Dojo plugin is ready, if we could mop-up the portlet plugin ticket, we could apply the caching patch to the HEAD, and get started on the 2.1.x series. Having AJAX as a plugin rather than a theme will also benefit many people :) -Ted. On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Yeah, I still need to confirm nothing is broken in core, except the tooltips which I know are not working. By the way Dojo 0.4.2 was released, how was the upgrade made last time? Drop the dojo files and add the new ones? musachy On 3/24/07, Ted Husted [EMAIL PROTECTED] wrote: As I believe the Ajax/Dojo plugin is ready, if we could mop-up the portlet plugin ticket, we could apply the caching patch to the HEAD, and get started on the 2.1.x series. Having AJAX as a plugin rather than a theme will also benefit many people :) -Ted. On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - 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: XWork build failing
When I run it, here's what's in my ActionContextTest.txt --- Test set: com.opensymphony.xwork2.ActionContextTest --- Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec You aren't seeing that? -- James Mitchell The Ruby Roundup http://www.rubyroundup.com/ On Mar 24, 2007, at 10:20 AM, Claus Ibsen wrote: Is it just me or is surefire not a bit strange on the xwork project? Could you try this: mvn clean mvn surefire-report:report And then look in target/site/surefire-report.html. Then click on the first test - ActionContextTest. It should have only 8 tests. but the list is much bigger on my report, probably about 60-80 tests. It looks like it's tests from other unit tests classes got mixed in. It's also wrong in the TEST-.xml files in the target/surefire- reports folder. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa? threadID=72225messageID=135519#135519 - 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: Japan Sites Rules
Addicted to porn? Help Yourself, with out risk of embarrassment. Affordable, No software for people to see. Keep your same Internet provider. No text based filtering to interfere. http://www.safefromsites.com/help.html Life is like a video game. Where you start, the characters you will meet, how long your session will last, and where you can go are pre programmed. -predestination The type of character you want, how much you achieve. and the path you pick , is up to you. -free will choose the right path - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=52486messageID=135643#135643 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
