Writing Scalable <st1:City><st1:place>AJAX</st1:place></st1:City> Web Applications

 

UI Tips

Writing Scalable AJAX Web Applications

 

By Andrew Flick and Anthony Lombardo

 

We ve already seen the many benefits associated with AJAX-enabled Web applications, but how do such applications affect your Web server? Without careful planning and design, the effects of AJAX can be crippling to your production server.

 

One key benefit of an AJAX-enabled Web application is reduced page-load time. This is accomplished by spreading the load over multiple asynchronous requests for data, instead of the normal single request/response associated with an http connection. While this technique is beneficial for the client browser and end user, it can be detrimental to a Web server under light to moderate load and catastrophic to a server subjected to heavy traffic.

 

To demonstrate this, let s take a look at a simple example. Suppose you ve built an AJAX-enabled Web application that uses an XML file as the back-end data store. Think of the client-side functionality as a black-box that simply requests data via an asynchronous XmlHttp request. The server is responsible for streaming text/xml content back to the client.

 

When creating such an application, the endpoint for the asynchronous requests deserves careful attention. You might be inclined to use an ASPX page to stream the response in the Page_Load event; in most scenarios however, using an ASPX page is overkill. A better performing solution would be to create an HttpHandler designed solely to handle the asynchronous data requests. This method streamlines the request/response process, ensuring the quickest possible response times; it also reduces the resources needed to serve up the response.

 

Creating a custom HttpHandler is a simple task in Visual Studio 2005. Right-click the Web site in Visual Studio s Solution Explorer and choose the Add New Item menu option from the context menu. Once the Add New Item dialog box appears, choose Generic Handler.

 


 

A custom HttpHandler must implement ProcessRequest, which is where all the action happens. Here is the code that would be necessary for the use case described above:

 

<%@ WebHandler Language="C#" Class="DataHandler" %>

using System;

using System.Web;

public class DataHandler : IHttpHandler {

 public void ProcessRequest (HttpContext context) {

     context.Response.ContentType = "text/xml";

     System.Xml.XmlDocument doc = this.GetFileList(context);

     System.Xml.XmlTextWriter writer = new System.Xml.XmlTextWriter(context.Response.OutputStream, System.Text.Encoding.UTF8);

     string requestedNodePath = System.Web.HttpUtility.UrlDecode(context.Request.Params["nodePath"]);

     if (requestedNodePath != null && requestedNode.Length >> 0)

     {

         System.Xml.XmlNode node = doc.SelectSingleNode(requestedNode);

         if (node != null)

         {

             node.WriteTo(writer);

         }

     }

     writer.Flush();

     writer.Close();

     writer=null;

     context.Response.Flush();

     context.Response.Close();

     context.Response.End();

     doc = null;

 }

 private System.Xml.XmlDocument GetFileList(HttpContext context)

 {

     System.Xml.XmlDocument fileList = null;

     fileList = new System.Xml.XmlDocument();

     fileList.Load(context.Server.MapPath("filelist.xml"));

     return fileList;

 }

 public bool IsReusable {

     get {

         return false;

     }

 }

}

 

While this handler seems uncomplicated, how well does it actually perform? Running a quick test using Microsoft Application Center Test (ACT) shows an abysmal 25 Requests per Second (RPS) being served up. The XML response data returned by the handler was only a few hundred characters, so a problem must be occurring in the server-side processing.

 

Look closely at the code and you ll notice that in order to serve up the response, the handler must first load the XML file into an XMLDocument. In a non-AJAX d page, this wouldn t be much of a problem because all the data would normally be transmitted in a single request/response. However, in an AJAX-enabled page, every client visit may spawn multiple requests. Each of those requests then causes the server to reload the data, incurring the same performance penalty over and over again.

 

Luckily, there s a simple solution for this problem. Because the data is remaining static, it doesn t need to be reloaded for each request. Instead, the XMLDocument can be loaded once, and placed into the application cache. Now the job of the handler is a simple task of retrieving the document from the cache, finding the requested node, and streaming it back to the client.

 

A quick tweak to the GetFileList method to use the application cache should yield better results:

 

private System.Xml.XmlDocument GetFileList(HttpContext context)

{

   System.Xml.XmlDocument fileList =null;

   fileList = context.Cache.Get("filelist") as System.Xml.XmlDocument;

   if (fileList == null)

   {

       fileList = new System.Xml.XmlDocument();

       fileList.Load(context.Server.MapPath("filelist.xml"));

       context.Cache.Add("filelist", fileList, null, System.Web.Caching.Cache.NoAbsoluteExpiration, new TimeSpan(0, 30, 0), System.Web.Caching.CacheItemPriority.Normal, null);

   }

   return fileList;

}

 

Running this improved handler through the same ACT test again now yields an incredible 300 RPS.

 

As you can see, the amount of processing required to serve up the response to an AJAX request can have serious implications on the overall performance of your application, as well as the health of your Web server. Because of the nature of an AJAX application, there are more requests being made per client visit, making it critically important that your request and response handling is as lightweight as possible. Keeping this in mind when designing your application will ensure that it will scale well as the number of concurrent users increases.

 

Andrew Flick is Product Manager - NetAdvantage Windows Forms Technologies & TestAdvantage for Infragistics, Inc. Prior to joining Infragistics, Andrew played an avid role in presenting on emerging .NET technologies throughout the Midwest to a variety of User Groups as well as numerous Student Groups. As an active member of the INETA Academic Committee, Andrew has authored content on building successful User Groups, as well as numerous white papers on building an effective community. A Microsoft MVP, Andrew joined Infragistics in July of 2004 as a Technology Evangelist, where he was responsible for the creation of reference applications and authoring .NET technology articles for industry leading publications, as well as the world wide delivery of Infragistics Technology demonstrations. Andrew currently serves as Infragistics Product Manager for NetAdvantage Windows Forms Technologies & TestAdvantage. As product manager, he spearheads the product management and strategies of Infragistics Windows Forms Product Lines from establishing the direction through delivery. Working directly with the Director of Development, he sets the direction, plans, and manages product development. Contact Andrew at mailto:[email protected].

 

Anthony Lombardo is Product Manager of NetAdvantage - ASP.NET Technologies for Infragistics, Inc., and is responsible for spearheading product management and strategies for Infragistics ASP.NET product line, working directly with the Director of Engineering to set the direction, plan, and manage product development. Prior to joining Infragistics, Anthony served as a Network Administrator for North Brunswick Board of Education and worked for Rutgers University in their technical support division. Since beginning his career with Infragistics in 2000, Anthony has been involved with every aspect of the development cycle, including playing a key role in the creation of the Presentation Layer Framework for ASP.NET, assisting in the creation and implementation of Infragistics Visual Studio 2005 project plan, and determining the product feature set for NetAdvantage 2005 for Visual Studio 2005. Contact Anthony at mailto:[email protected].

 

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish