During development of an AJAX-like web application, I was beginning work on a page that would receive an Xml request and return an Xml response. I learned that I don't want to use a full Aspx page because that would waste resources by forcing IIS to do its full viewstate build-up and tear-down processing. Our page isn't a web-form at all--we just need to do pure Xml processing. An Ashx document was suggested as the ideal solution, but I've never used one.
Using Visual Studio 2010, we begin by adding a new Generic Handler:
The default code is straightforward, creating a class with a name that matches the file name. It implements the System.Web.IHttpHandler interface, with the
ProcessRequest method simply returning a text message.
It works right out of the box. A simple Get request to the file returns the expected message. This should be perfect for my Xml-over-Http demo!
Since the whold reason for using Ashx is performance, I decided to compare this page to a standard Aspx page using www.webpagetest.org.
The Ashx page came back in 0.332s. Subsequent tests came back in 0.294s and 0.289s.
The Aspx page first came back in 0.680s, twice as slow as the Ashx handler! A second try came back in under 0.3s, probably because IIS was using its pre-compiled copy of the page. It will be interesting to test Ashx performance as the page gets more complicated, but it looks like Ashx is the way to go in implementing my Xml-over-Http handler.
It was tempting to think that I might replace all my aspx pages on this site with ashx, but there are a few circumstances where I do need to use SessionState variables and SessionState is not wired up for ashx requests. It's clear that ashx pages are useful and perform well, but aren't suitable for every circumstance.