Small followup to that: In a result JSP (success.jsp in the example app for WW 2.0) I placed 50 calls of either:
<ww:textfield .../> or <ww:vmtextfield ../> Average response time when using the JSP-based components: 162ms Average response time when using the velocity-based components: 38ms That's a performance boost of 4X. Also, I don't have a test for this, but it "feels" like velocity also scales more. Here's my less scientific test: Using the JSP-based example from above, I held down "reload" so that about 40 http requests were sent in. The time for the final 20 requesst to be handled took on average 40 -seconds-. When using velocity under the same test, the final 20 requests took on average 1.4 seconds. That's a scalability factor of about 30X! -Pat ----- Original Message ----- From: "Patrick Lightbody" <[EMAIL PROTECTED]> To: "os-ww" <[EMAIL PROTECTED]> Sent: Monday, February 03, 2003 10:17 PM Subject: [OS-webwork] Velocity as the UI widgets [WW 2.0] > I just ran some tests, inspired by Scotts work on getting Velocity in place > for the UI tags. I took it one step further and got rid rd.include() > entirely (Like Scott had mentioned) and the performance boost was icredible. > > Basically, if we lock down to using velocity for the -UI tags- (note, this > means that JSP views would still work), we get like a 10X performance > increase as well as a huge scaling increase. I mean, it's so huge that it > would be dumb for us not to take it. And mind you, I ran these tests on > Orion and Resin, two of the fastest JSP implementations. > > So I'm going to un-propose my suggestion about using SiteMesh for the UI > tags and instead propose that we stick 100% to only supporting > velocity-based taglibs. Your JSP views will still look and act exactly the > same: > > .... > <ww:textfield ... /> > ... > > The only difference is that instead of the TextFieldTag issueing an > rd.include() request to some unknown URL (JSP or velocity), it uses Velocity > to write -directly- to the JspWriter: > > template.merge(context, pageContext.getOut()); > > All the same support would exist (themes, tweaking, etc), but it would just > be much faster. The downside is that if you have custom UI widgets, you'll > have to convert them to velocity. > > Thoughts? Actually, don't write back to this. Instead, just show up to the > dev meeting tomorrow. > > -Pat > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
