Ajax Apps — Cleaner Connections, Less Bandwidth? Maybe Not…

Posted: April 29th, 2005
Filed under: Uncategorized


Lately there has been a flurry of discussion in the blog world about Web applications that use JavaScript asynchronously, generally with XML, to create a different style of Web application.  A few notable examples (such as Gmail, Google Suggest, and Snaptax), and others use this model to create very rich and often faster user experience as compared to standard, click-and-wait Web applications.

A few folks have dubbed this Web development model, Ajax — as tempted as we are to go on a rant on why we need a new acronym for something that has been around for quite a while (especially one that reminds us of a cleaning product) — we abstain, courteously.  Instead, let’s consider if an Ajax model will affect Web administrators and performance.< ?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />

At first, the answer would seem to be that Ajax will make everybody happier — users and administrators alike.  Consider that in most sites, as users move from page to page, many of the requests are redundant.  For example, from one page to the next, the framing HTML is often very similar, but yet you have to retransmit since you can’t just send the content down (or can you? — every here of delta encoding?).  Of course, you also will often reuse images, CSS, and scripts from page to page.  This won’t be too problematic if you are using proper cache control, but if you don’t there could be tremendous waste with retransmissions or needless 304 responses.  An Ajax-based application would theoretically get rid of some of this.

The basic idea would be the primary files of the Web app would get downloaded in the beginning and only needed data or logic would be fetched later on.  If properly coded, one could expect a significant reduction of bandwidth over the visit.  However, you will find that request activity will likely shift to be less spread out, potentially causing more bursts of requests on servers.  In some sense, Ajax does reduce some requests, but it also just shifts others around.

Now, save the potential for bursts, it would seem that Ajax makes life much better for overtaxed severs… but wait just a second.  Once empowered with Ajax thinking, we are noticing that many Web applications built want to have more two-way communication.  Since the server can initiate connections to browsers, the only way to accomplish this is through polling.  So, in many Ajax applications, you see timers firing every 60 seconds (or much less) requesting status reports from a server to see if updates are required.  Houston, we have a problem here.  If you think RSS readers cause problems, try hundreds of users polling regularly, keeping the server busy with uncacheable requests because they left their window on your page when they went to lunch.  Speaking from experience, we have an application that has 30 some-odd people polling all day long for status updates on their screens, and the server isn’t too happy.  Oh, and your logs are practically useless and quite massive with this going on…  Hmmmm…  Product need here?  So folks, when you use your new Ajax power — remember you might make some users happy, and you might make some admins mad and require them to put in much more $$$ equipment to deal with your fancy, whiz-bang app.

Oh, and before closing, I can’t help myself…  Rant mode on: Ajax is not new; it has been called inner browsing, remote scripting, and a slew of other things — so please people, stop with the acronym invention.

Signed,

Pat from the Port80 Web Team

8 Comments »


8 Comments on “Ajax Apps — Cleaner Connections, Less Bandwidth? Maybe Not…”

  • Theoretical rambling. If you use cache control, you still are faced with screen refreshes, right? Dimishes user experience which is the point.

    Enginners at big companies seemed to have worked this out. Granted they have the server and bandwidth requirements. How many of these apps really "poll" all the time?

    Posted by: Carlo at 10:33 am on May 2nd, 2005
  • Any form of "real time" or communications app built in AJAX repolls almost every 60 seconds. There is no way to initiate a connection to a browser without a more complicated technology in play — so that is what the developers tend to be doing. There are tremendous numbers of chat apps, often for tech support, as well as others that do it this way as well. That’s how Port80 found out about the problem.

    Cache control will not help as much in most AJAX apps. The way they are built is that they are doing only XML and text transfers. Gzipping requests automatically will help much more so here, but they are generally not requesting static files from what we are seeing out there…

    As for big companies, you must be referring to traditional client/server applications and not web based applications? In the Web space at least, if they have figured it out, we don’t see it. There are still lots of gear and bandwidth being thrown at the problems and folks are spending much effort with firms like Port80 Software and appliance vendors trying to improve performance — which is getting tougher as the apps are changing their model. We really don’t think this is as trivial a problem as your handwave seems to suggest.

    But rambling, yes, we like to do that… you caught us there. : )

    Posted by: Pat @ Port80 at 11:39 am on May 2nd, 2005
  • Implementing AJAX Using ASP.NET 1.1:

    http://www.15seconds.com/issue/050526.htm

    AJAX is an acronym that stands for Asynchronous JavaScript and XML. AJAX’s strong point is that it allows data on a page to be dynamically updated without the browser having to reload the page. This article offers a brief introduction and description of AJAX and then provides some sample code illustrating its usage.

    Posted by: Jeremiah @ Port80 at 9:51 am on May 27th, 2005
  • Intro to Ajax and the Ajax Library for .NET http://weblogs.asp.net/wallym/archive/2005/08/14/422523.aspx

    Posted by: Chuck @ Port80 at 9:51 am on August 15th, 2005
  • What’s your opinion on "slow polling"

    http://www.plasser.net/blog/continuous_ajax_requests

    Posted by: scott at 1:12 am on October 14th, 2005
  • Thanks for your comment, Scott. See this post for an answer:

    http://www.port80software.com/200ok/archive/2005/10/14/854.aspx

    Posted by: Chris @ Port80 at 11:58 am on October 14th, 2005
  • Ajax would definitely be the future of computing if the server could push to the browser without having to wait for a browser request. Is the ball in the court of the browser makers (Microsoft) to come up with a cross-platform solution?

    Posted by: gavacho at 2:43 pm on March 16th, 2006
  • They (MS) are perfectly positioned for this, yet we don’t see them making that leap yet. Perhaps, as IIS becomes more of a Web Service platform with the emergence of WCF/Indigo, we will see more of this push capability:

    http://www.tgdaily.com/2006/03/22/longhorn_server_preview_to_continue/

    Cheers,

    Port80

    Posted by: Chris @ Port80 at 5:00 pm on March 27th, 2006