Some more info on this: 1) As I mentioned earlier, the way the templates are merged in velocityResult is much different from how things were handled in ww1. WW1 used the VelocityServlet, which did some writer pooling. I tried to implement the same thing but it didn't appear to help much; I just don't know enough about how to work with Velocity. I didn't see any performance increase. If someone who knows velocity could look at this part, we could probably figure out what's happening. 2) I set the velocity property "file.resource.loader.cache=true" in velocity properties. That did improve performance. Pages that took on average about 300-500 ms to load now load in 100-150ms. The problem is that this turns off the ability to play with velocity pages during development, so it's probably best saved for production, as they recommend in the velocity docs.
The real issue is still out there, though. Setting the cache property certainly improved performance, but in ww1 those same page loads averaged 30-50 ms. So setting the cache property on still doesn't figure out what's going on with velocity results. I feel like we're getting closer, though.... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Farquhar Sent: Thursday, August 21, 2003 10:36 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Performance diff bw ww1 and ww2? Just quickly - are we caching the velocity templates? AFAIK (and that ain't much regarding velocity), the speed increase in velocity is achieved by caching the parsed templates. Cheers, Scott Jason Carreira wrote: > I've spent some time profiling these in Tomcat with OptimizeIt and it > definitely looks like it's something in VelocityResult and how it uses > Velocity. In Tomcat, the ww2 version is talking 600+ ms, the ww1 > version is 30-40ms. Under Resin, it's about 10ms for the ww1 version > and 100ms for the ww2 version... > > 54% of the time is spent under line 85: > > t.merge(context, response.getWriter()); > > Another 44% is under line 72: > > Template t = velocityEngine.getTemplate(this.location); > > Anyone have any idea why this is so much slower with WW2 than with > WW1? They're both merging a template... I must admit I don't know that > much about Velocity. > > Jason > > >>-----Original Message----- >>From: Drew McAuliffe [mailto:[EMAIL PROTECTED] >>Sent: Friday, August 15, 2003 4:41 AM >>To: [EMAIL PROTECTED] >>Subject: RE: [OS-webwork] Re: Performance diff bw ww1 and ww2? >> >> >>I've created two sample applications that show the >>performance difference. The problem is that I have two zip >>files, one for each project (Eclipse/MyEclipse project) and >>they're each over 5MB (because of supporting jars). That >>means I can't attach them to a Jira issue. I'd like to send >>them out so you can see what I'm talking about. >> >>Basically, the sample apps each do exactly the same thing but >>one uses ww1 and the other xwork/ww2. A simple "company" >>object is loaded up and the page is filled using the custom >>"pageset" construct I've created. It's a cached configuration >>object that says how a page should be laid out (it's >>something I use to help codify common page design, so I don't >>have to screw around with html/jsp/velocity or what have you >>for pages that all follow the same layout pattern). I realize >>that this pageset thing is unusual but it's not the problem, >>since it renders fine with ww1. The sample apps don't do any >>database calls, so it's obvious that the performance hit >>comes somewhere in the render cycle. >> >>What I'm seeing, consistently, on the same server, is the following: >>ww1: 10-20ms load >>ww2: 190-250ms load >> >>That's a pretty big difference, and again, these pages aren't >>doing anything special or any database calls. I'm guessing >>that part of it is in how velocity is being used, or perhaps >>something to do with searching the ognl stack (since the >>stack is used for things like getting object properties or >>creating instances of utility classes). >> >>One other thing: the copy of the webwork2 jar I'm using has >>been modified to add a "$webwork" utility class to the >>velocity stack on a request. This copies the way things were >>done in ww1. of course, my fumbling around with this in ww2 >>may have caused the performance hit. I can supply the >>modifications upon request. They're also in a current JIRA >>issue as attachments, at issue # WW251. >> >>Please let me know how I can get the sample projects to >>anyone who's interested. I think this simple example would go >>a long way towards understanding how to optimize ww2. >> >>Thanks, >> >>Drew >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On >>Behalf Of Drew McAuliffe >>Sent: Monday, August 11, 2003 3:20 PM >>To: [EMAIL PROTECTED] >>Subject: [OS-webwork] Re: Performance diff bw ww1 and ww2? >> >> >>I've moved from Tomcat to oc4j and the numbers have improved >>considerably. So at this point, it's not a complete hassle >>like it was before. Though now I'm interested to see how fast >>the old version would have worked on oc4j. >> >>The results I was getting were consistent across both Tomcat >>4.1.x and 5.0. It seems to happen with the render cycle, as I >>said. I haven't had time to profile it but I'll get on it >>this week. I have a feeling, and this is just a guess, that >>it might have something to do with the similarity between >>ognl and velocity syntax? I'm not sure but I should have some >>sort of information soon. >> >>One of the other things I'm going to try to do is use the ww2 >>tags to duplicate some of what I'm doing in velocity macros >>now. I'll try to replace my usage of macros with component >>tags and see how it works out. >> >> >> >> >> >>------------------------------------------------------- >>This SF.Net email sponsored by: Free pre-built ASP.NET sites >>including Data Reports, E-commerce, Portals, and Forums are >>available now. Download today and enter to win an XBOX or >>Visual Studio .NET. >>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet > > _072303_01/01 > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single > machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the same time. Free trial click > here:http://www.vmware.com/wl/offer/358/0 > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support ------------------------------------------------------- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
