Pathfinder Blog
Topic Archive: Ajax Performance

37 JavaScript benchmarks

Brian Dillard, Wednesday, February 13, 2008 @ 12:08 pm

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

Continue reading »

Topics: ,

agile ajax Agile Ajax

The painful art of prognostication

Brian Dillard, Tuesday, September 25, 2007 @ 7:35 am

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

Topics: , ,

agile ajax Agile Ajax

Object Pooling and Reusing XMLHttpRequest in IE

Dietrich Kappe, Thursday, August 24, 2006 @ 9:00 am

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

Topics: , ,

agile ajax Agile Ajax

Echo2 vs GWT

Dietrich Kappe, Tuesday, July 4, 2006 @ 9:00 am

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.

Topics: , , , , , ,

agile ajax Agile Ajax

Sprajax? Security Scanner for AJAX

Dietrich Kappe, Monday, May 29, 2006 @ 9:00 am

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.

Topics: , , , ,

agile ajax Agile Ajax

AJAX and Security

Dietrich Kappe, Friday, May 26, 2006 @ 9:00 am

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.

Topics: , ,

agile ajax Agile Ajax

Stomping out the Misconceptions

Dietrich Kappe, Monday, May 22, 2006 @ 9:00 am

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.

Topics: , , , ,

agile ajax Agile Ajax

Not There Yet: COMET with Apache and Jetty

Dietrich Kappe, Tuesday, May 16, 2006 @ 9:00 am

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.

Topics: , , , ,

agile ajax Agile Ajax

COMET: Socket Hungry AJAX

Dietrich Kappe, Friday, May 5, 2006 @ 9:00 am

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.

Topics: , , ,

agile ajax Agile Ajax

Ajax: The “Husky” Client

Dietrich Kappe, Friday, April 28, 2006 @ 10:28 am

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."

Topics: , ,

agile ajax Agile Ajax

Again on Scalability

Dietrich Kappe, Friday, April 21, 2006 @ 2:32 pm

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.

Topics: , ,

agile ajax Agile Ajax

Jetty 6’s Continuation Mechanism for Ajax

Dietrich Kappe, Thursday, April 20, 2006 @ 9:00 am

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.

Topics: , , , , ,

agile ajax Agile Ajax

Webtop - I Already Hate It

Dietrich Kappe, Wednesday, April 19, 2006 @ 9:00 am

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.

Topics: , , , , ,

agile ajax Agile Ajax

Asynchronous Processing in Ajax Apps

Dietrich Kappe, Friday, April 14, 2006 @ 9:00 am

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.

Topics: , , ,

agile ajax Agile Ajax

Google Calendar: Not As Fat as Other Ajax Apps

Dietrich Kappe, Thursday, April 13, 2006 @ 12:20 pm

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.

Topics: , ,

agile ajax Agile Ajax

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

Blogroll

WordPress