Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <46BCA7B2.2090703@omnytex.com>
Date: Fri, 10 Aug 2007 14:00:18 -0400
From: "Frank W. Zammetti" <fzlists@omnytex.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: struts1 or struts 2?
References: 
 <B617E796C78D0B4197B7ABF4736E9EAA0408B00B@CBSCC-X3-MBVS01.ad.cibc.com>
In-Reply-To: 
 <B617E796C78D0B4197B7ABF4736E9EAA0408B00B@CBSCC-X3-MBVS01.ad.cibc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Asthana, Rahul wrote:
> By the way, have any of you done any performance metrics on an ajax based implementation vs a non ajax based one?

Early on we did a proof-of-concept that did exactly this... what we 
found was that the AJAX version was universally perceived as being 
faster, even when a few cases actually weren't (i.e., client-side 
processing took longer than the equivalent server-side version).

The conclusions we drew were:

1. You have to strive to minimize the amount of Javascript executing as 
a result of each AJAX call.  There is a line that when crossed means the 
server can actually render the whole page fresh and the browser can 
display it faster than AJAX+Javascript updates.

2. There is a balance you need to strike between the number of AJAX 
calls and size of each AJAX response... there is again a line that when 
crossed means that X number of small AJAX requests takes more time than 
one non-AJAX "transaction".

3. There is definitely tuning that needs to be done in terms of moving 
static resources off to the web server, making sure your AJAX responses 
are tight, things like that.  The very biggest impact we found, recently 
actually, was in moving all images, CSS, Javascript and other static 
content off to the web server... especially when your doing AJAX and 
your making numerous small requests vs. one or two larger non-AJAX 
requests, not having to hit the web server makes a huge difference... 
remember that in most cases, there is a small number of connections 
available between the web server and app server (we had 5 I believe) 
even though you may have 100 connections/threads available on the web 
server (and probably app server).  That's where we found the most 
significant bottleneck... we're talking making an app twice as fast just 
by moving static content off the app server!

4. Aside from the static content thing, this is the biggest point to 
emphasize: you need to get your developers thinking a different way then 
they probably are used to... they need to, for lack of a better way to 
put it, trust the client more.  For instance, we had developers that 
insisted on putting objects in session, even though myself and other 
senior developers were telling them it'd be better to keep things in 
Javascript objects client-side... they would tell you now we were 100% 
right :)  This isn't a criticism of them though, when your used to doing 
things a certain way, and they basically work well, you don't want to 
change, especially given what many people have historically thought 
about Javascript and client-side development.  But once you get the 
mindset changing, you'll see a really huge improvement in performance of 
your apps because the fundamental design leads to better performance 
naturally.

> rgds
> Rahul

Frank

-- 
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
  (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
  (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
  Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org