Agile Ajax

37 JavaScript benchmarks

JavaScript benchmarks have achieved greater visibility in the Ajax era, but they have a long and proud history. I did a little digging and came up with this round-up of profiling suites past, present and future. Many of them mix pure JS tests with DOM tests. Those that focus more on a specific type of operation are broken out into a separate list after the jump, as are browser-specific benchmarks and a bunch of cobweb-covered older suites.

Recent Benchmarks

• SunSpider 0.9: The Webkit team's JavaScript benchmark. (Announcement here.) (Jeff Atwood's post here.)
• Javascript Library Performance Test Roundup: From the folks behind PBWiki. (Results page here.)
• Ajax and Flex Data Loading Benchmarks: From James Ward, RIA Cowboy using his own Census tool.
• JavaScript Engine Speeds: John Resig of jQuery's September 2007 post comparing Rhino to SpiderMonkey, Tamarin and JavaScriptCore.
• A Study of Ajax Performance Issues: Coach Wei uses the jsLex profiling tool to put the entire Ajax stack through its paces.
• Evaluate Low Level JavaScript Performance Characteristics: Speaking of jsLex, it was created by the folks from RockStarApps, who pitted it against September 2007's best and brightest browsers in this post.
• JavaScript Speed Tests: From Celtic Kane Online.
• General Browser Load-Time Test: The first in an entire suite of browser tests from the Non-Troppo site.
• Double-Dollar Speed Test: An interactive suite that tests the selector functions of various big Ajax libraries.
• Computer Language Benchmarks Game: A clever, snarky "game" in which various language implementations can be tested against one another.
• i-Bench: The now-discontinued benchmark suite used by PC Magazine can still be downloaded in its archival edition.

The painful art of prognostication

They say science fiction is rarely actually about the future; it's really an exploration of present-day fears and anxieties, interrogated through a metaphor of the future. William Gibson himself - the father of cyberpunk - has given up the future in favor of exploring our technological present in compelling novels such as Pattern Recognition and the brand-new Spook Country.

I couldn't help but think about science fiction when I read this "strategy letter" by Joel Spolsky of "Joel on Software" fame. Spolsky looks at a number of current trends in the Ajax world, draws parallels between them and the original emergence of desktop computing, and concludes that the future looks a lot like Windows. In Spolsky's vision, one or two powerful Ajax toolkits will become the de facto new platform/operating system for the next era of application development.

I cry bullshit not because Spolsky's discussion is illogical or ill-informed, but because it's presented with such certitude. If my time in the blog echo chamber has taught me anything, it's that the guy who seems most sure of himself is probably the one blowing the most hot air. Folks have an insatiable appetite for strong opinions, repeated loudly. Everybody wants to know what the future will bring. But the best most commentators can hope for is to surf the currents of the present and catch of peek at what's beyond the next wave. Extrapolating a bunch of disparate trends 5 or 10 years into the future is just an exercise in rhetorical prowess. Joel's a great storyteller, but like most storytellers he's primarily interested in spinning a great yarn. By all means give his theories a whirl, but don't expect capital-T Truth. Nobody can tell the future. To believe otherwise is science fiction.

1984 is a powerful book precisely because Orwell didn't have to make a lot of shit up. He had Nazi Germany and the Soviet Union under Stalin as models for what he was doing. He only had to dress it up a little bit, sort of pile it up in a certain way to say, "this is the future." But the reason it's powerful is that it resonates of history. It doesn't resonate back from the future, it resonates out of modern history. And the power with which it resonates is directly contingent on the sort of point-for-point mimesis, like sort of point-for-point realism, in terms of what we know happened.

--William Gibson, via Boing Boing

Object Pooling and Reusing XMLHttpRequest in IE

Thousands of XMLHttpRequest objects are needlessly being killed every second of every day. Cruel web developers are thoughtlessly creating new XHR objects, even though they can now be reused in every browser, including IE. As a public service, I thought I'd show one approach for pooling XHR objects, and saving memory and CPU time.

All kidding aside, pooling reusable objects is easy and can save a great deal of processing time, especially in IE. Here is my example XHR pool. It relies on good programmer behavior, i.e. they need to release any XHR objects using XHRFactory.release().

var XHRFactory = (function(){
 // static private member
 var stack = new Array();
 var poolSize = 10;
 
 var nullFunction = function() {}; // for nuking the onreadystatechange
 
 // private static methods
 
 function createXHR() {
  if (window.XMLHttpRequest) {
       return new XMLHttpRequest();
     } else if (window.ActiveXObject) {
       return new ActiveXObject('Microsoft.XMLHTTP')
     }
    }

 // cache a few for use
 for (var i = 0; i < poolSize; i++) {
  stack.push(createXHR());
 }
 
 // shared instance methods
 return ({
  release:function(xhr){
   xhr.onreadystatechange = nullFunction;
   stack.push(xhr);
  },
  getInstance:function(){
   if (stack.length < 1) {
    return createXHR();
   } else {
    return stack.pop();
   }
  },
  toString:function(){
   return "stack size = " + stack.length;
  }
 });
})();

You would use this object as follows:

var xhr = XHRFactory.getInstance();
var url = "http://www.xyz.com/someresource/....";
// do the operation
xhr.open("GET", url, true);
xhr.onreadystatechange = function() {
        if (xhr.readyState==4) {
                // if "OK"
                if (xhr.status==200) {
                // process the response
        }
                XHRFactory.release(xhr);
        }
};
xhr.send("");

We know from Eric Pascarello and Pava Keely that as long as you perform an open on the XHR object before you set the onreadystatchange, you can reuse the object in IE. Some simple benchmarks shows that allocating 100 XHR objects 500 times sees a performance improvement of over 50% in Firefox and a whopping 93% in IE6.

So, think before you needlessly create those XHR objects. The application you save could be your own.

Technorati : ajax, object poolong, performance optimization, xmlhttprequest

Echo2 vs GWT

Back on June 6th I made a note of this post by Echo2 creator Tod Liebeck at The Server Side, entitled Comparing the Google Web Toolkit to Echo2, but never got around to blogging about it. Tod gives a fairly succinct description of both GWT and Echo2:

GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript. GWT limits the developer to a subset of the Java 1.4 libraries. GWT applications can be served by any web server, such as Apache, without the need for server-side processing.

Echo2 applications are compiled to Java byte code and run on a Java server. Their Java code is executed by Echo2's "Web Application Container" layer, which sits atop a Java Servlet. On the web browser, the Echo2 "Client Engine" communicates user input to the Web Application Container via AJAX requests, with the server responding with directives to perform incremental updates to the state of the client web browser.

He goes on to analyze other points of comparison, including architectural, performance and legal issues. A good comparison by one of the AJAX worlds leading developers.

One thought here is that many folks have held out a GWT as a tool for writing widgets for other frameworks such as ZK and Echo2. I've been going through the Javascript infrastructure of GWT and it seems there's a whole lot of plumbing that stands in the way of making this a reality. More on this later.

Sprajax? Security Scanner for AJAX

I came across an open source AJAX security scanner called Sprajax. From the Denim Group's press release:

Sprajax is the first web security scanner developed specifically to scan AJAX web applications for security vulnerabilities. Denim Group, an IT consultancy specializing in web application security, recognized that there were no tools available on the market able to scan AJAX. AJAX allows web-based applications a higher degree of user-interactivity, a feature with growing popularity among developers.

Denim Group developed this innovative tool that will revolutionize security assessments by providing a more thorough diagnosis of security vulnerabilities within the AJAX code that other web security scanners are not designed to read. The software then produces a report of possible weaknesses for developers to remedy.

It's Open Source, so I decided to download it and see what the hype was about. First, the application is written in C#. Second, you will need SQL Server to get it to run as the results are stored in SQL Server and are pulled into reports using stored procedures. Finally, the application doesn't do all that much.

The application takes an application URL as a parameter and has three main functions.

• You can "footprint" the application, i.e. scan it for Javascript files and web services.
• You can "fuzz" the application, i.e. pass garbage into the web services to see if they will barf.
• You can display the results of the previous two functions.

Essentially, the footprint function spiders the application, detects the framework used, finds Javascript files included, and discovers web services used. The fuzz function uses those discovered web services and passes some garbage into them and sees if they returned error conditions. There are just a few problems with this tool, however:

• The tool only detects the Atlas framework. No Dojo, DWR, etc.
• It only detects SOAP web services used by the Atlas framework. No REST, no framework specific calls.
• It doesn't scan the Javascript files for XHR calls, another place to find calls back to the server.

The fuzz function only tests robustness and in a fairly limited way, i.e. will the app go belly up when you pass in garbage data. Typically, security scanning tools test for known exploits of web application frameworks, a much more useful approach.

Finally, consider that many AJAX frameworks make use of dynamic XHTML and Javascript to drive content and navigation. This tool just sucks in the content and looks for URL's. It wouldn't find even one link in an Echo2 application, for instance.

Overall, there isn't much here. It has the feel of something that a journeyman programmer put together over a weekend. I applaud the Denim Group for releasing an Open Source tool, but the hype in their statement is wildly inaccurate. You can likely write something in Perl in a few hours that would do all of this and more.

AJAX and Security

Lots of articles like this one from eWeek broach the subject of AJAX and security but give few answers. The most insightful quote from the article is from the Dojo man:

Panelist Alex Russell, co-founder and project lead for The Dojo Toolkit, a popular AJAX framework, said, "It's worth noting that the fundamental problems with browser security and Web application security haven't changed in five years—most rely on a single root of trust, and AJAX doesn't change that. Wider spread use of cross-domain content distribution," which is not new with AJAX, is part of the issue. "The short version is still, Don't trust the client."

Right on. But beyond "nothing to see here...move along, move along," can we at least categorize security concerns and explain how they might apply to AJAX?

The security issues, as I see them, fall into two distinct categories: end-user and server. End-user issues revolve mostly around privacy. A user wants control over what information is revealed to third parties. The server issues, on the other hand, revolve around exposing services that a malicious user can exploit by subverting the client. (There are hybrid versions of these, such as third parties launching attacks on sites using cross domain content, etc.) AJAX has added a wrinkle to both of these issues.

On the client side:

• XHR has made it difficult for the user to know whether information about their behavior is being transmitted back to the server. Solution: give users a way of seeing what is happening with XHR and other "invisible" communications.
• It is easy for developers to overlook the need for SSL or some sort of encryption when confidential information is sent back to the server. Solution: Give the use better insight into how information is about to be transferred.
• Larding in new functionality into the browser raises the chance that security holes might be opened up. Solution: decouple the browser from the OS (IE) and institute a sandbox approach. Don't hold your breath for this one.

Should we give the user more control over XHR, i.e. give them an option to disable certain features of the browser? With the increased complexity of these apps, even tech-savvy users might find it difficult to evaluate the security of the application.

On the server side:

• Ad-hoc code - We've learned to protect ourselves from things like injection attacks and the like on the server side through the use of webapp frameworks. Opening up lots of little services using ad-hoc AJAX tools can lead to repeating these mistakes. Solution: consider using a server-side component GUI framework like Echo2 or ZK to avoid this issue.
• Reliance on too much business logic in the client. No matter how much you obfuscate your code, it is still accessible to the client. This is the pitfall with client-side component GUI frameworks like Tibco GI and OpenLaszlo. Solution: you can try and fight against this by making the services they access as simple as possible and dependent on cryptographically secure session information. I just wouldn't do anything mission critical with this.
• Application complexity - It used to be that if someone compromised your site, they would deface it, install a rootkit or grab some credit card numbers. Now, a cracker might instead modify your AJAX application to send malicious Javascript to the client. Since "view source" ain't what it used to be with DHTML and eval'd Javascript, this sort of compromise might be hard to detect. Solution: regular regression testing against the app is probably the best you can do.

The Open Web Application Security Project has some good resources on webapp security, but they're a little bit behind on AJAX. One of their suggested approaches that I can heartily recommed is using mod_security, sort of a stateful firewall for webapps.

Stomping out the Misconceptions

A reader pointed out this blog entry from Infoworld, Mercury: AJAX has its drawbacks. It's from the middle of April, but it is still worth responding.

"AJAX is incredible where people are starting to adopt it and it immediately causes a lot of problems because it's not very structured," said Rajesh Radhakrishnan, vice president of Application Delivery at Mercury. Several Mercury executives met with InfoWorld editors at Mercury offices in Mountain View, Calif. on Tuesday morning.

"We've seen tons and tons of problems," with AJAX, Radhakrishnan said. In testing for functionality and regression, Mercury has seen an increased number of regressions in AJAX, said Radhakrishnan.

As a workaround, Radhakrishnan suggests using AJAX for the cutting edge part of UI development, to enable interactions between the client and server in which the server is able to respond to client requests later. "For the rest of it, you don't really use AJAX,""Radhakrishnan said.

It is precisely using AJAX for the "cutting edge" parts of a UI that causes the problems. Calling an architectural principle like AJAX "not very structured" betrays an ignorance of the topic. It's like calling web service "not very structured" because people are using raw java.net sockets to do everything.

This post is from April of 2006, not 2005 when this sort of comment would have been excusable. Now there are several stable intermediate forms such as DWR that allow for fairly structured development of AJAX solutions on top of existing webapp frameworks. Further, there are already some more advanced forms such as Tibco GI, OpenLaszlo, ZK and Echo2 that allow for development of sophisticated desktop-type apps.

Mercury may be trying to discourage folks from developing AJAX apps until they've had a chance to update their testing software to keep pace. I suggest that they work harder on their next release instead.

Not There Yet: COMET with Apache and Jetty

I had intended to marry the nice Apache2 event MPM and Jetty 6 with Continuations in order to achieve a thrifty, thread-sparing COMET capable Java app. The idea is that the Event MPM module in apache frees up a thread when an open connection to the browser is snoozing and Jetty frees up a thread when the backend servlet is snoozing. There are two problems, however.

1. The Event MPM module seems to only snooze between requests. With COMET the need to snooze happens during a requests, i.e. we are expecting something to come back from the server.
2. The request handler module -- in this case mod_jk or mod_proxy_ajp -- and not the Event MPM module handles the socket connections to the servlet container. From my reading of the most recent SVN branch, the modules are using blocking I/O and not polling.

It seems there's still a bit of work to be done to make Apache and Jetty do the COMET dance.

COMET: Socket Hungry AJAX

From back in late March, Alex Russel over at IrishDev writes about a new AJAX technique, calling it COMET. What is COMET? Basically the browser makes a request of the servers, but the server keeps the socket open over a long period of time.

[COMET applications] all use long-lived HTTP connections to reduce the latency with which messages are passed to the server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.

Does it scale? We've talked about this stuff before when we spoke about Jetty Continuations. I wrote then that

I don't like this method because it is wasteful in terms of sockets and threads; also, it is likely to stress stateful firewalls, load balancers, etc., and may break in lots of client environments.

I stand by that statement. Beyond the issue of migrating these connections between nodes in a load-balanced cluster (yes, you could close the connection and have the client automatically reopen the connection), there are serious scaling issues.

One of the things that made HTTP based applications scalable was that they made use of small, stateless requests. This meant you could handle requests from an order of magnitude or more users than a comparable stateful application.

It's true that the typical AJAX polling for async updates also puts a burden on the server, firewall, load balancers, etc., but that depends partly on the frequency of the polling and the number of clients doing the polling. Even if I have 10,000 users polling the server every half second, I may still only have a few hundred sockets open at any one time if the request/response size is small and the user's network latency is low.

Modifications to server software like Apache and Jetty to conserve resources like threads and make use of IO multiplexing is a first and probably necessary step. Maybe I'm making too much of this stateful thing. We may have so much application state information floating around on the server side anyway that is will dwarf any OS and network resources that COMET and related technologies seek to spend.

Update 1: DWR's next release should have an implementation of COMET that they are calling "Reverse AJAX." More interesting, however, is the fact that they are releasing an API that allows one to write Javascript by writing Java.

Ajax: The "Husky" Client

Scott Dietzen over at Zimbra has a post in a continuing series on AJAX scalability. Besides coining the humorous term "Husky" Client to describe AJAX -- not quite thin, but not quite fat -- he makes some excellent points about the importance of design and choosing the appropriate browser/server boundary for an application in order to minimize the impact on the server.

I thought the following early paragraph was a nice observation by someone who clearly has a bit of experience developing applications:

Traditional fat client applications, on the other hand, off-load all of the UI and most of the business logic (modulo stored procedures and triggers) from the server to the client. Fat client app's could nevertheless hammer their servers simply by not being sophisticated about how much and how often data was being requested---that is, data shipping to the client can be more expensive than function shipping to the server (with stored procedures, triggers, et al). With a reasonably smart design, however, fat client applications typically use more client and less server CPU per operation than a corresponding server-centric application.

I think the generation of RIA's (Rich Interaction Application) that are about to sweep the web are likely going to repeat many of the mistakes of the client/server age. As Scott points out, how poorly these applications perform is going to be in part dependent on how well they are designed. As Santayana wrote, "Those who cannot remember the past are condemned to repeat it."

Again on Scalability

Since my rant started flowing, I just thought I'd pull this out of the comments section at Ajaxian.com:

Beyond becoming multi-threaded, AJAX is beginning to open up the web to new types of applications, ones that are document centric (word processors, modeling tools, etc.) rather than data and transaction centric, i.e. all those rectangular CRUD applications that make up 99.9% of webapps. It also means that the sorts and types of rich client interactions are going to dwarf the traffic that we see today.

That means 1. abandoning the forms-and-reports way of writing webapps (which will break when you try to write something like rational rose as a webapp) and moving to the component GUI model (like Swing, Winforms, etc.) and 2. being very clever about the frequency and size of your XHR conversations with the server. From my unscientific tests (Yahoo mail and Google calendar) it seems that some are winning and some are losing the battle on fat XHR. I don’t think any amount of JSON or compressed XML magic will solve the problem of poor design.

I think the right way to achieve all of this is by moving AJAX/Webapp development to component GUI application frameworks. Properly done, they have the potential to hide all of the messy bits like exposing too much of your business logic on the client side, optimizing XHR requests for components that have empty server-side event listeners, reducing the impedence mismatch between the Javascript/CSS/XHTML world and the business logic.

Those who don’t move in this direction will be stuck building and maintaining ever more complex applications because they didn’t make the shift to a new design. It’s time to think of the browser simply as a display server.

Jetty 6's Continuation Mechanism for Ajax

I've touched on the topic of updates and asynchronous processing before. My preferred method of performing updates between the browser and server is via a polling mechanism that returns quickly. An alternative is to open up an XHR connection and keep it open to wait for a response (or a timeout). I don't like this method because it is wasteful in terms of sockets and threads; also, it is likely to stress stateful firewalls, load balancers, etc., and may break in lots of client environments.

Nevertheless, if you want to keep a connection open for notification initiated by the server, this is the way for now. And the Jetty 6 server has at least addressed the thread issue with Continuations.

Behind the scenes, Jetty has to be a bit sneaky to work around Java and the Servlet specification as there is no mechanism in Java to suspend a thread and then resume it later. The first time the request handler calls continuation.getEvent(timeoutMS) a RetryReqeuest runtime exception is thrown. This exception propogates out of all the request handling code and is caught by Jetty and handled specially. Instead of producing an error response, Jetty places the request on a timeout queue and returns the thread to the thread pool.

When the timeout expires, or if another thread calls continuation.resume(event) then the request is retried. This time, when continuation.getEvent(timeoutMS) is called, either the event is returned or null is returned to indicate a timeout. The request handler then produces a response as it normally would.

Sockets are still consumed, though. Hopefully the next servlet specification will address some of these issues. Until that time, this may be a good workaround.

Still, my preference is to keep everything except for the display logic on the server side, and that includes handling complex communication with async processing.

Update 1: ActiveMQ can make use of Jetty 6's continuation mechanism.

Update 2: Greg Wilkins has some more extensive thoughts on using Jetty 6 to scale Ajax apps.

Webtop - I Already Hate It

A reader emailed me this old article from CNN Money discussing the concept of the webtop, i.e. that

A killer app no longer requires hundreds of drones slaving away on millions of lines of code. Three or four engineers and a steady supply of Red Bull is all it takes to rapidly turn a midnight brainstorm into a website so hot it melts the servers.

What has changed is the way today's Web-based apps can run almost as seamlessly as programs used on the desktop, with embedded audio, video, and drag-and-drop ease of use. Behind this Web-desktop fusion are technologies like Ajax (asynchronous JavaScript and XML), Macromedia's Flash, and Ruby on Rails. We'll spare you the technical details; suffice it to say that these technologies are giving rise to a new webtop that may one day replace your suite of desktop applications.

I already hate the term "webtop," though I've used it myself in the past. The article goes on to discuss the various webapps that are starting to move into areas once reserved for desktop applications, then lists of a few noteworthy apps, such as 37signals campfire chat client.

The conclusion? We'll all be doing our word processing over the web from now on.

Now I like a little bit of breathless hype as much as the next guy, but this is over the top. Yes, webapps are going to change, but there are certain limitations to the medium that will make the webtop a much tamer place:

• Reliability and performance - why aren't most desktop apps in corporate environments served up as client/server apps? The technology is there; the kinks of client/server have mostly been worked out. License sharing could save tons of money. The benefits of reliable, centralized storage and ease of collaboration seem pretty obvious. Yet the most we see is networked storage of documents. The reason? Even on a corporate network, performance and reliability are not high enough to make client/server computing for desktop apps attractive.
• It's more than just CRUD on speed - even after the widespread introduction of the WIMP (Windows, Icons, Menus, Pointing device) environments in the 80's, it took a while for programs to mature beyond GUI versions of Lotus 1-2-3. We didn't see precursors to Photoshop until a few years after the introduction of the Mac. Most webapps today are still glorified CRUD (Create, Read, Update, Delete) engines. Writing the more substantial applications will take a good bit of work, not just a few cans of Red Bull (or Jolt!, sniff).
• Writely ain't Word - more like Wordpad. If Writely was out as a desktop app, it wouldn't get a second look. Yes, there is a need for a Word-compatible, easier, less bloated, free word processor, but they never seem to make it. Yes, a web based word processor that saves your work more frequently than an occasional submit is kinda cool. But the truly cool part is the collaboration feature of Writely, and honestly, there are other, better solutions for that.
• Can I Use it Offline? - You're not going to be online all the time. The moment you have desktop versions that can function independent of the server, is it still Ajax or a Javascript/Browser app with save capability?

This hype around Ajax is really starting to remind me of the first dotcom boom (See FauxJAX for a good sendup of this). I had a few venture capitalists back then asking me to look at business plans that added "the web" to their business models. My rule for evaluating these was always the same: what does the web add? Most times it didn't change anything; it was just another marketing channel. For others, like online classifieds, it removed distribution costs. For the social networking type businesses, it made it easier and less costly to jumpstart the network effect.

So, for those going gaga over Ajax, ask yourself, what does Ajax add? If you can't come up with a good answer, odds are it doesn't add a thing.

Asynchronous Processing in Ajax Apps

Most web applications are still request driven, i.e. the browser makes a request and backend state is updated as a response to that request. There is some backend processing, but usually that processing is very losely coupled with the webapp, updating a backend data store.

Many more advanced apps make use of web services, MDB's, JMS, and other approaches to perform asynchronous processing. The need for asynchronous processing in webapps has been mostly confined to some special cases, requiring extreme scalability or performance. But now with the advent of Ajax, many new webapps are going to have to perform ongoing background processing in order to update front end displays. Some of these processes are going to exceed the time you want an XHR to be open. Or maybe you want to perform some backend processing tightly coupled to the session and UI, rather than loosely tied to the persistent store.

I've used open source tools like Mule, ActiveMQ and the like for some of these things. It does make life a bit easier when doing async processing, but moving to these new technologies will involve a bit of a learning curve for most webapp developers. Sorry, guys, the pain isn't over.

Google Calendar: Not As Fat as Other Ajax Apps

Again a non-scientific look at an Ajax application and whether it delivers on the "many smaller requests" advantage of Ajax. Last time we looked at the old and new Yahoo Mail. There the traffic looked pretty bulky for Ajax, i.e. the new Yahoo Ajax Mail was sending large amounts of data with XHR and making more requests than the old non-Ajax app.

This time we don't have an old app to compare it to, and yes it's apples and oranges, i.e. we're talking about calendaring, not email, so the information sent back and forth is likely to be smaller. Again, the disclaimer: not scientific. Just accessing the app and trying to excercise as many of the features as possible. Here are the numbers:

(The count is the number of hits. All the other figures are in bytes. The figures are for response data sent from the server and doesn't include the size of the request data sent from the browser.)

                               

Count	93
Average	4393.108
Median	110
10th	44.2
25th	66
75th	581.5
90th	2385.6
Max	331424

At first glance, the communication seems pretty bulky, but if you subtract out the honking Javascript file at 331424 bytes, your average comes down to 838. So, overall, this Ajax app seems pretty efficient. In particular, I performed many more actions on the browser than are reflected in the measely 93 hits in my proxy log. That suggests that plenty of the business logic is in the browser.

One more thought: as Ajax apps become more sophisticated, we may want to have web servers and proxies and such start logging both the response and request sizes.

Note: I'm not sure there's any help for the ugly logo, no matter how well the app performs.

Yahoo Mail, Ajax and Your Server

I recently did a little unscientific comparison between the old Yahoo mail and the new Beta Ajax interface. The idea was to strap a non-caching proxy in front of the browser for a day each, clear the cache and see how they compared.

I fully expected to see the increase in requests and a decrease in request size that everyone talked about. I did see the former, but not much of the latter, as it turns out. The average request size was smaller for the Ajax version, but not that much smaller.

While this test wasn't scientific -- I just used my yahoo mail account as I usually do throughout the day -- my educated guess is that the temptation to add lots of features to the new whiz-bang interface is the culprit.

Here, without further ado, are some of the facts and figures (count is number of requests. All others are in bytes):

Ajax Yahoo Mail

Count	9848
Average	3392.27
Median	543.5
90th Percentile	6593.2
25th Percentile	94
10th percentile	43
75th percentile	1604.75

Old Yahoo Mail

Count	7329
Average	4153.74
Median	195.5
90th Percentile	15052.4
25th Percentile	70
10th percentile	43
75th percentile	1880

What does this mean to you and your infrastructure requirements? Unless you exercise incredible discipline in pushing back on feature creep, you are likely to have Ajax apps that make more and bigger requests.

Remember when 1MB was more computer memory than anyone would ever need, or when car makers used the extra energy in those hybrid vehicles for greater fuel efficiency instead of more power of hybrid SUV's?