James Newton-King : ASP.NET

Speeding up ASP.NET with the Runtime Page Optimizer

James Newton-King — Sun, 19 Oct 2008 04:40:00 GMT

Earlier this year I worked on an exciting product called the Runtime Page Optimizer (RPO). Originally written by the guys at ActionThis to solve their website’s performance issues, I had the opportunity to develop it with them and help turn the RPO into a product that works on any ASP.NET website.

How RPO works

At its heart the RPO is a HttpModule that intercepts page content at runtime, inspects it, and then rewrites the page so that is optimized to be downloaded to the client. Because the RPO is a module it can quickly be added to any existing ASP.NET website, creating instant performance improvements.

What RPO optimizes

The RPO does three things to speed up a web page:

Reduces HTTP requests
Reducing the number of resources on a page often produces the most dramatic improvement in performance. A modest sized web page can still take a significant amount of time to load if it contains many stylesheets, scripts and image files.
The reason for this is most of the time spent waiting for a web page to load is not for large files to download but from HTTP requests bouncing between the browser and the server. The RPO fixes this by intelligently combining CSS and JavaScript text files together and merging images through CSS spriting. Fewer resources means less time wasted from HTTP requests and faster page loads.

Compresses Content
RPO minifies (whitespace removal) and zip compresses JavaScript and CSS files, as well as the ASP.NET page itself. Compression reduces page size, saves bandwidth and further decreasing page load times.

Caching
The RPO ensures all static content has the correct HTTP headers to be cached on a user’s browser. This further decreases "warm" page load times and saves even more bandwidth. When resources change on the server, the client-side cache is automatically refreshed.

Other stuff

Every site is different so the RPO has extensive configuration options to customize it to best optimize your ASP.NET application. RPO has been used on ASP.NET AJAX, MVC, SharePoint, CRM, EpiServer and DotNetNuke websites.
Lots of thought has been put into performance. The RPO caches all combined content and supports load balancing. Once combined content has been cached the only thing that happens at runtime is lightweight parsing of HTML, which is darn quick. I know because I wrote it that way
The RPO supports all browsers, including new kid on the block: Chrome. RPO is even smart enough to take advantage of features only available in certain browsers and supply specially customized content to further improve page load times.
The industrious people at RPO are making a version for Apache.

Working on the RPO was a great experience. Some very smart people are behind it and everyone contributed something unique to make RPO the awesome tool that it is today.

RPO is out now and a fully featured trial is available at getrpo.com. Check it out!

Update:

I noticed there is a question about the RPO on StackOverflow (I've been using StackOverflow a lot lately, excellent resource). The question discussion has some positive comments from users who have tried the RPO out.

WebRequestDetailedErrorEvent

James Newton-King — Thu, 10 Aug 2006 07:46:00 GMT

Download DetailedErrorEvent - DetailedErrorEvent dll and C# source code

One of the least talked about new ASP.NET 2.0 features, and one of my favorites, is the health monitoring system. Designed to help you monitor the status of a deployed website, the ASP.NET health monitoring system makes what could potentially be a chore easy. With just a few lines in your site’s web.config you can automatically log a variety of events to a file, a database or even send an email to an email address.

While overall health monitoring it is a great new feature for ASP.NET, the WebRequestErrorEvent class provides disappointingly small amount of information. Raised when an unhandled exception is thrown during a web request, only basic information about the request that caused the error is provided such as the URL, the user host address and the authenticated user. Vital information like the request headers, form values, cookies and server variables are missing, making debugging the error more difficult than it needs to be.

WebRequestDetailedErrorEvent

The WebRequestDetailedErrorEvent class inherits from WebRequestErrorEvent and includes the information that the base class is missing.

One interesting aspect of the health monitoring events is that they are written asynchronously. While this allows them to be buffered and written without impacting performance, it also means that a copy of the request details need to be taken as HttpContext.Current will be null when the FormatCustomEventDetails method is called.

private void Init(Exception exception)

    // FormatCustomEventDetails is called outside of a web request

    // need to take a copies of all the web request information to log

    HttpContext context = HttpContext.Current;

    if (context != null)

        HttpRequest request = context.Request;

        _cookies = new HttpCookie[request.Cookies.Count];

        request.Cookies.CopyTo(_cookies, 0);

        _httpHeaders = new NameValueCollection(request.Headers);

        _form = new NameValueCollection(request.Form);

        _queryString = new NameValueCollection(request.QueryString);

        _serverVariables = new NameValueCollection(request.ServerVariables);

    else

        _cookies = new HttpCookie[0];

        _httpHeaders = new NameValueCollection();

        _form = new NameValueCollection();

        _queryString = new NameValueCollection();

        _serverVariables = new NameValueCollection();

WebRequestDetailedErrorModule

Unfortunately there is no seamless way to automatically raise the new web request error event instead old so a new HttpModule is required to do it for us. WebRequestDetailedErrorModule attaches a method to the Error event of the HttpApplication object and then raises WebRequestDetailedErrorEvent when a web request exception goes unhandled. Not all exceptions raised the default event so some logic is required to filter them out.

private void RaiseErrorEvent(object sender, EventArgs e)

    HttpApplication application = (HttpApplication)sender;

    HttpContext context = application.Context;

    Exception exception = context.Error;

    // unwrap exception if top exception is an HttpUnhandledException

    if (exception is HttpUnhandledException && exception.InnerException != null)

        exception = exception.InnerException;

    HttpException httpException = exception as HttpException;

    // don't log file not found exceptions

    if (httpException != null && httpException.GetHttpCode() == 404)

        return;

    // viewstate exceptions raise a WebViewStateFailureAuditEvent, not an exception event

    if (httpException != null && httpException.InnerException is ViewStateException)

        return;

    WebBaseEvent.Raise(new WebRequestDetailedErrorEvent("An unhandled exception has occurred.", this, WebEventCodes.WebExtendedBase + 3005, 0, exception));

The old event will still be raised so if you may want to modify your web.config to not log events numbered 3005.

Usage

To use the WebRequestDetailedErrorEvent simply add the module to your website’s httpModule section.

<httpModules>

    <add name="WebRequestDetailedErrorModule" type="Newtonsoft.DetailedErrorEvent.WebRequestDetailedErrorModule, Newtonsoft.DetailedErrorEvent"/>

</httpModules>

And that’s it. The new error event is now raised whenever an unhandled exception is thrown from a web request. Note that if you haven’t already setup ASP.NET to log health monitor events you can find out how here.

Download DetailedErrorEvent - DetailedErrorEvent dll and C# source code

WebDialog 1.1 released

James Newton-King — Sat, 15 Jul 2006 00:21:00 GMT

WebDialog 1.1 has been released.

Much improved support for Atlas is the primary feature of this WebDialog release.

What's New:

New Feature - Improved Atlas support in Internet Explorer and Opera.
Bug Fix - Fixed validators nested inside a dialog with client script enabled not displaying their error message when they failed.

Preventing Spam With An ASP.NET CAPTCHA Control

James Newton-King — Mon, 29 May 2006 09:34:00 GMT

The source and dll for the project can be downloaded here: CaptchaControl.zip

About

A CAPTCHA image displays text that is readable to humans, but not to computers. The concept is useful because it provides a means to filter out automated programs while allowing real users to pass through. Bots for example, which spam comments on weblogs and other dynamic websites, are a fairly pervasive problem and even a regularly new and low traffic blog like this was getting dozens of spam comments every day. CAPTCHA is a means to stop them while still allowing real users to post.

CaptchaControl is an ASP.NET server control that is designed to start working by just being dropping onto the page, without any modification. This version is based off Michael Trefry’s implementation, which is in turn based off Dan Burke’s. My update fixes a couple of issues around storing the code in a browser cookie and adds features like client validation.

CatchaControl Overview

The CaptchaControl class is a composite control and encapsulates the CAPTCHA image, a textbox for capturing the result and a validator for verifying the correct code was entered. It handles hooking all the controls together, pointing the image src towards the image handler and maintaining the state of the code, which is stored encrypted in a hidden form field and then decrypted on postback.

protected override void OnPreRender(EventArgs e)

    base.OnPreRender(e);

    RegenerateCode();

    Page.ClientScript.RegisterHiddenField(ClientID + "__hidden", _encryptedCode);

    Page.RegisterRequiresPostBack(this);

    SetChildProperties();

bool IPostBackDataHandler.LoadPostData(string postDataKey, NameValueCollection postCollection)

    _encryptedCode = postCollection[ClientID + "__hidden"];

    _code = Encryptor.Decrypt(_encryptedCode, GetKey(), GetIV());

    return true;

CaptchaControl has a number of properties for modifying its behavior such as the text of the error message, whether to display for authenticated users and whether the code should be validated on the client with JavaScript (note that the unencrypted code will be included with the page if this is enabled). It also an optional LayoutTemplate property of ITemplate that allows the encapsulated controls layout to be customized.

Generating the CAPTCHA Image

The CAPTCHA image is generated by CaptchaHandler, a HttpModule. Parameters in the querystring, including the encrypted code data, are passed to a class than handles generating the image, which is then rendered to the response.

void IHttpHandler.ProcessRequest(HttpContext context)

    HttpRequest request = context.Request;

    HttpResponse response = context.Response;

    string encryptedCode = request.QueryString["code"];

    string code = Encryptor.Decrypt(encryptedCode, CaptchaControl.GetKey(), CaptchaControl.GetIV());

    int width = Convert.ToInt32(request.QueryString["width"]);

    int height = Convert.ToInt32(request.QueryString["height"]);

    CaptchaImageGenerator captchaImage = new CaptchaImageGenerator(code, width, height);

    response.Clear();

    response.ContentType = "img/jpeg";

    response.Cache.SetCacheability(HttpCacheability.NoCache);

    captchaImage.RenderImage(response.OutputStream);

Usage

Register the CaptchaHandler by adding the following to your web.config’s httpModule element.

<add verb="*" path="captchahandler.axd" type="Newtonsoft.CaptchaControl.CaptchaHandler, Newtonsoft.CaptchaControl"/>

To add the CaptchaControl to a page simply place it where you want it to be displayed:

<%@ Register TagPrefix="ncc" Namespace="Newtonsoft.CaptchaControl" Assembly="Newtonsoft.CaptchaControl" %>

<ncc:CaptchaControl runat="server" ID="CaptchaControl" />

The IsValid property on the page will automatically be set when the page’s validators, including CaptchaControl, are evaluated on postback.

private void btnSubmit_Click(object sender, EventArgs e)

    if (IsValid)

        // logic

The important question: Does it work? Since adding CAPTCHA validation to this blog comment spam has dropped from dozens each day to zero.

The source and dll for the project can be downloaded here: CaptchaControl.zip

Logging JavaScript Errors To ASP.NET

James Newton-King — Tue, 02 May 2006 10:16:00 GMT

Over the past few years a huge jump in the complexity of JavaScript has occured on the browser, resulting in richer, more responsive and user friendly web applications. Unfortunatly this shift does not come without cost.

Greater complexity on the client means more room for bugs, and without some effective means to log them you are left in the dark about problems until users are driven to complain.

Solution Overview

The client exception logger comprises of three parts: a script on the client that catches the exceptions and sends them to the server, a HttpHandler on the server that receives the error details and logs them, and an ASP.NET control that links the two together.

Details logged include the following:

JavaScript exception message, line and file name
Date and time
IP Address
User agent (browser and platform details)
Session ID

Catching and Sending the Error on the Client

Whenever an exception is not caught in JavaScript it triggers an onerror event on the browser's window object. It is comparable to ASP.NET’s Application_Error event in the global.asax.

When the page is downloaded a ClientLogger object is created and a function is attached to the onerror event. That function calls a method on ClientLogger object which will send the error details to ASP.NET on the server using the XMLHttpRequest object. This is done asynchronously and does not effect the user.

var logger = new ClientLogger({handlerUrl:'../../ClientLogger.axd',sessionID:'2rnbawbkzuovsw55ymvflz45'});

window.onerror = function(message, url, line) { logger.Log(message, url, line); };

Receiving and Logging the Error on the Server

When sending the error data back to the server, rather than the page calling back to itself, the logger posts the details a custom HttpHandler. This is done to minimize side effects or performance issues of creating the page again.
Note that the handler does not contain any logic for logging the error details. Instead it uses the new ASP.NET 2.0 Web Event feature, and raises a custom WebJavaScriptErrorEvent event.

WebBaseEvent.Raise(new WebJavaScriptErrorEvent(jsMessage, this, jsUrl, jsLine, pageUrl, userAgent, sessionID));

Packaging Everything Together in a Control

The ASP.NET control includes the JavaScript file (embedded in the dll) on the page and registers some JavaScript that creates the client object and attaches it to the onerror event. To enable JavaScript error logging include the control on your master page:

<%@ Register TagPrefix="ncl" Namespace="Newtonsoft.ClientLogger" Assembly="Newtonsoft.ClientLogger" %>


<ncl:ClientLogger runat="server" />

And register the HttpHandler in the web.config:

<add verb="*" path="clientlogger.axd" type="Newtonsoft.ClientLogger.ClientLoggerHandler, Newtonsoft.ClientLogger"/>

Consuming The Web Event

The great thing about ASP.NET Web Events is that you can decide how you want to log the event, and it is simple as modifying your web application's web.config file. For example in just a few lines you can configure ASP.NET to log all errors to your database or send them to an email address. The rule below for example will log all errors to the database. You can learn more about using ASP.NET Web Events here.

<add name="SqlServerWebErrorLogger"

    eventName="All Errors"

    provider="SqlWebEventProvider"/>

And that's it. You will now know about JavaScript errors as they happen.

The source and dll for the project can be downloaded here: ClientLogger.zip