RE: [OS-webwork] Xwork/WebWork2 under extreme load

Patrick Lightbody Fri, 09 Jan 2004 00:44:01 -0800

Title: 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

RE: [OS-webwork] Xwork/WebWork2 under extreme load

Reply via email to