Since we're on the subject of performance: I believe that response.setContentLength(...) improves quite the performance of servlet requesting. Does WW (1 & 2) sets this ContentLength when returning different View Results? I noticed that for JasperReports it does. Isn't it possible for velocity/jsp to also do this or there are any technical blocking issues for doing this?
Personally, I'm using some GzipFilter which sets it, so generally speaking it isn't such a big problem, but when not using Gzip (because pages are too small, or client doesn't support it (BTW, do you know if Google Crawlers support gzip?)), it would be nice for WW to set it, if indeed it improves the performance. Fernando Martins On Friday 09 January 2004 09:30, Francisco Hernandez wrote: > were these optimizations and tweaks on the actual monthlist jsp page or > something in xwork? > > Patrick Lightbody wrote: > > Actually ? a bit more of an update. Monthlist in 2.0 is now running > > 50% - 100% faster due to some small Ognl optimizations and some other > > minor tweaks. > > > > 1.4.1 (from CVS) gets times around 70ms for monthlist > > > > 2.0 (from CVS) gets times around 45ms > > > > Pat > > > > -----Original Message----- > > *From:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *On Behalf > > Of *Patrick Lightbody > > *Sent:* Thursday, January 08, 2004 11:40 PM > > *To:* [EMAIL PROTECTED] > > *Subject:* RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > > OK, I have an update on the performance issue (when compared to > > 1.4.1-dev): > > > > I was able to get WW 2.0?s monthlist.jsp to be at about the same speed > > as WW 1.4?s monthlist.jsp (or within 5%) by doing the following: > > > > ˇ Change TextTag to _/not/_ make a getText() method call in the VS but > > rather actually iterate through the VS and look for objects that are > > instanceof TextProvider and then make the necessary call statically > > (rather than through reflection) > > > > ˇ Remove timer and logging interceptors from webwork-default.xml ? > > they add about 10% overhead it turns out! > > > > IfTag is still adding another 10% overhead that 1.4 doesn?t seem to > > have, and so if I can figure out why it is being slow (the slowness > > comes from Ognl it seems, which might make it tough) we?d actually end > > up with being slightly faster. I?m not too worried about that though. > > > > Overall, I think the EL performance in 2.0 is very good now. The real > > concern is with the Velocity stuff and making sure it isn?t doing any > > ?stupid? things. > > > > -Pat > > > > -----Original Message----- > > *From:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *On Behalf > > Of *Daniel Pfeifer > > *Sent:* Thursday, January 08, 2004 11:11 PM > > *To:* '[EMAIL PROTECTED]' > > *Subject:* RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > > Yeah, I do use Beta 2. In fact: It is a checkout from just before > > christmas eve. > > > > -----Original Message----- > > From: Patrick Lightbody [mailto:[EMAIL PROTECTED] > > Sent: den 8 januari 2004 17:56 > > To: [EMAIL PROTECTED] > > Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > > Significantly faster would also be a bit incorrect. WebWork 2 is faster > > than 1.4 in the area of raw EL support (math, boolean statements, etc). > > It is about 50% slower than WebWork 1.4 whenever the ValueStack is > > involved (which is almost all the time), which is something we indeed to > > look in to as a final piece of work before 2.0 final goes out. > > > > Daniel, are you using beta 2 (or later)? Until beta 2, the VS was about > > 6X slower than it is now due to a bug. > > > > Pat > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Hani Suleiman > > Sent: Thursday, January 08, 2004 8:46 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load > > > > The threadlocal issue is a red herring, ww1 uses it and it's > > significantly faster than ww2. > > > > Daniel Pfeifer wrote: > >> That might be slightly off-topic, but it fits to the subject. However, > >> > >> personally I think that webwork is quite slow once you do some serious > >> > >> work with it. We are testing a webwork-based website on a P4 3Ghz plus > > > > 1 > > > >> gig of RAM and some requests really do take ages (especially when the > >> ValueStack is involved) to complete. I hope you find some ways to > >> improve it before WW2 goes final. > >> > >> /Daniel > >> > >> -----Original Message----- > >> From: Patrick Lightbody [mailto:[EMAIL PROTECTED] > >> Sent: den 8 januari 2004 17:10 > >> To: [EMAIL PROTECTED] > >> Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > >> > >> > >> Well, about a year ago when we had the initial XW meetings, it was > >> decided to keep the TL for now. Maybe post-2.0 we'll find ways to > > > > slowly > > > >> migrate away from it. I agree though, ThreadLocals suck ass. > >> > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> Scott Farquhar > >> Sent: Wednesday, January 07, 2004 6:00 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load > >> > >> On Wed, Jan 07, 2004 at 11:56:28PM +0100, Jens Riboe wrote: > >> > What was the design rationale for putting it in thread local > > > > storage? > > > >> > This works for servlets, but it may cause mysterious bugs in Swing > >> > applications, every time one uses a worker thread for a time > > > > consuming > > > >> > UI event. > >> > > >> > How about putting state info, like actionCtx, config, etc into > >> > a single XWork object and then let the impl choose to store it > >> > appropriately. The ctx can then be created from that object. > >> > > >> > For a servlet one can use thread-based singleton, like above > >> > or put it into the servletCtx, and the actionCtx can be created and > >> > >> stored > >> > >> > into the request. > >> > > >> > For a Swing app, it generally suffice to go for a classloader > >> > >> singleton, > >> > >> > aka static variable, for both config and actionCtx. > >> > >> I like the way that PicoContainer has done it: > >> > >> public interface ObjectReference { > >> Object get(); > >> > >> void set(Object item); > >> } > >> > >> Then there can be a ThreadLocalObjectReference, or a > >> SingletonObjectReference as needed. > >> > >> I've needed to change the way that things are stored in Pico, and it > > > > was > > > >> a 5 line change due to this abstraction. > >> > >> So you have the ActionContext take an ObjectReference of where to > > > > store > > > >> itself? > >> > >> Cheers, > >> Scott > >> > >> > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: Perforce Software. > >> Perforce is the Fast Software Configuration Management System offering > >> advanced branching capabilities and atomic changes on 50+ platforms. > >> Free Eval! http://www.perforce.com/perforce/loadprog.html > >> _______________________________________________ > >> Opensymphony-webwork mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >> > >> > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: Perforce Software. > >> Perforce is the Fast Software Configuration Management System offering > >> advanced branching capabilities and atomic changes on 50+ platforms. > >> Free Eval! http://www.perforce.com/perforce/loadprog.html > >> _______________________________________________ > >> Opensymphony-webwork mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Perforce Software. > > Perforce is the Fast Software Configuration Management System offering > > advanced branching capabilities and atomic changes on 50+ platforms. > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Perforce Software. > > Perforce is the Fast Software Configuration Management System offering > > advanced branching capabilities and atomic changes on 50+ platforms. > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
