Well, there's caching that you can set for the resources, which means that every page is cached. That wasn't how things were set by default in ww1, or at least not how I had them set in the examples I gave Jason. That's a performance enhancement you can make when moving to production and it prevents you from having updates to your velocity files be applied automatically. I'm positive that this cache setting was turned off when I used ww1, and I still saw the performance difference.
I'm looking into the VelocityResult right now. In ww1, it looks like the template merge was coming from WebWorkVelocityServlet, which relied on methods in its superclass, VelocityServlet. The way in which it merged templates is a lot different from what's going on in VelocityResult. There seems to be some sort of writer pool being implemented, along with wrapping the OutputStream in a VelocityWriter. I'm going to play around and see if I can't get things working in velocity result the way they worked in the VelocityServlet (which is a part of velocity, not webwork). If I need to store some sort of a pool, I'll probably hang it off of the velocity manager, since it looks like the VelocityResult is a throwaway object. Please correct me if I'm wrong. Drew -----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
