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]

Reply via email to