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

Francisco Hernandez Fri, 09 Jan 2004 01:34:41 -0800

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

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

Reply via email to