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]