Re: [OS-webwork] Velocity as the UI widgets [WW 2.0]
Could someone make a small note about what xw/ww uses from each dependency? If someone (*cough*pat*cough*jason*cough*) would even post something to the list about it, I'll put it up in the wiki. At the business meeting: And webwork has a small memory foot print, only ~20k Why is our WAR file so big then? Well it's dependent on a few other jars A few? At least eight actually... so far. Why? Who knows, next slide please. --Erik On Mon, 3 Feb 2003, Patrick Lightbody wrote: I agree, I had that convern as well. The current jars in lib/core are: beanutils logging collections digester ognl oscore velocity We could get rid of beanutils, digester, and collections. That's something XWork is using but really has no need to (we could parse the simple XML by hand). So yes, we would add velocity as a dependency. But performance is so much improved that it's well worth it (IMO). -Pat - Original Message - From: Joseph Ottinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 11:00 PM Subject: Re: [OS-webwork] Velocity as the UI widgets [WW 2.0] I'll be at the dev meeting, provided nothing comes up, but: my only qualm with using velocity for the UI tags is that it adds velocity dependency to WW, whereas right now, WW only requires commons-collections, commons-logging, digester, beanutils... oh, forget it. :) On Tue, 4 Feb 2003, [ISO-8859-1] Rickard Öberg wrote: Patrick Lightbody wrote: 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! As I may have mentioned we are basing our SiteVision CMS/portal product entirely on WebWork/Velocity. Based on benchmarks I've done the above sounds about right (e.g. an average page with about 10 Velocity portlets render in ~50ms, even under high load). Velocity is incredibly fast, and scales very well. Which is why I proposed that we switch to it for the UI tags. I'm happy to see that your tests verify this idea :-) /Rickard --- 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 - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld 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 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
Re: [OS-webwork] Velocity as the UI widgets [WW 2.0]
On Tue, Feb 04, 2003 at 04:16:34AM -0800, Erik Beeson wrote: Could someone make a small note about what xw/ww uses from each dependency? If someone (*cough*pat*cough*jason*cough*) would even post something to the list about it, I'll put it up in the wiki. I agree, I had that convern as well. The current jars in lib/core are: beanutils logging XSLT uses logging and any available Trax Parser/Transformer. (Note to the reader of this mailing list: Please strip quoted message to the minimum. I just had to remove 20++ lines of quoted signatures.) -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg01574/pgp0.pgp Description: PGP signature
RE: [OS-webwork] Velocity as the UI widgets [WW 2.0]
-Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 2:08 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Velocity as the UI widgets [WW 2.0] I agree, I had that convern as well. The current jars in lib/core are: beanutils logging collections digester ognl oscore velocity We could get rid of beanutils, digester, and collections. That's something XWork is using but really has no need to (we could parse the simple XML by hand). Where are we using BeanUtils and Digester? We ARE parsing the XML by hand, using a javax.xml.parsers.DocumentBuilder. I know I've used commons collections in some areas, but it may have been pulled out again. What are we using from oscore? Jason --- 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
Re: [OS-webwork] Velocity as the UI widgets [WW 2.0]
I've been wondering about this. Isn't OSCore, like, CORE? Why not put useful things in it and use it, the way it was done a while back? On Tue, 4 Feb 2003, Patrick Lightbody wrote: Where are we using BeanUtils and Digester? We ARE parsing the XML by hand, using a javax.xml.parsers.DocumentBuilder. I know I've used commons collections in some areas, but it may have been pulled out again. What are we using from oscore? BeanUtils isn't being used directly, but Digester requires it. We use digester to parse components.xml, which really isn't that important, since we parse the other XML by hand anyway. OSCore is used in very few places, we could probably pull it out for now. -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 - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- 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
RE: [OS-webwork] Velocity as the UI widgets [WW 2.0]
Sure, that works. -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 10:09 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Velocity as the UI widgets [WW 2.0] I'm willing to get up early. Would we like to reschedule it for 23 hours from now? -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 6:03 AM Subject: RE: [OS-webwork] Velocity as the UI widgets [WW 2.0] -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Yeah, I think the only way is to do it at around 8-9 AM EST, which means afternoon here, which means late at night down under. Any other time will mean that someone is asleep :-) Well, 9 AM here means 6 AM in California, where Patrick is. I don't know if there is a good solution --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld 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 =omething 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
Re: [OS-webwork] Velocity as the UI widgets [WW 2.0]
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
Re: [OS-webwork] Velocity as the UI widgets [WW 2.0]
Given that for some of us the dev meeting is at an unearthly hour of the morning :) (I am at GMT + 9.5) I'll comment here. Please can we have this in WW 1.3 ? What will it mean in terms of jars needed in our web application ? On Tue, 2003-02-04 at 17:17, Patrick Lightbody wrote: 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 -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- 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
