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
