IIS7 is for Developers - the RC0 story - Allan's Best Week Ever - Site Home

<system.webServer>Code Camp 8 Resources</system.webServer> for those paying attention ;) Thank you for attending my session at Code Camp 8 in the face of the LINQ goodness from Timothy Ng in the next room.

Here goes the long post...

The IIS team had a lot of time on their hands (1 non-critical security bulletin for IIS6) and they put it to good use! If you were present today, you heard me extoll the virtues of ASP.NET+IIS7, IIS7 extensibility, etc. but the sleeper hit of this product is how it will make your production debugging/troubleshooting easier. My simple demo - I encourage you to run it - aspires to showcase this.

Save the following (line numbers for readability only) into sleep.aspx and create a web application on Vista/Windows Server 2008 (Beta 3 will do).

   1:  <%@ Page Language="C#" Trace="true" %>

   2:  <script runat="server">

   3:      protected void Page_Load(Object src, EventArgs E)

   4:      {

   5:          Trace.Write("Sleep:Page_Load:Begin");

6:

   7:          int sleeptime = 15; // default is 15 seconds of sleep

   8:          if (Request["SleepTime"] != null)

   9:          {

  10:              sleeptime = int.Parse(Request["SleepTime"]);

  11:          }

  12:          Trace.Write("Sleeping for " + sleeptime.ToString() + " secs");

  13:          Trace.Warn("Sleeping for " + sleeptime.ToString() + " secs");

  14:          System.Threading.Thread.Sleep(sleeptime * 1000); // convert to millis

  15:          Trace.Write("Sleep:Page_Load:End");

  16:          Response.Write("waking up...");

  17:      }

  18:  </script

  19:  <html>

  20:  <head>

  21:      <title>sleepy page</title>

  22:  </head>

  23:  <body>

  24:  </body>

  25:  </html>

The 3 IIS7 features that I think will really resonate with developers around production troubleshooting are:

Currently Executing Requests - Ability to see currently running requests (how many problems could have been solved with just this feature!)
Failed Request Tracing - Ability to proactively set rules to trap exceptional events
Instrumentation - managed code (ASP.NET) instrumentation using Trace.Write/Warn and seeing these trace events in the same IIS7 trace logs.

The code stinks. Line 14 is a no-no in production, multi-user environments. Without IIS7, you are probably snapping memory dumps and post processing them *and/or* parsing through a ton of IIS logs with LogParser. Doable but not enjoyable and not efficient.

Currently Executing Requests

Spin up a browser or your favorite tool to hit sleep.aspx multiple times, perhaps with different query parameters, e.g., http://localhost/iis7demo/sleep.aspx?SleepTime=25.

View the current running requests:

C:\windows\system32\inetsrv>appcmd list request
REQUEST "f800000080000004" (url:GET /demo/sleep.aspx?SleepTime=35, time:18006 msec, client:localhost)
REQUEST "f700000080000002" (url:GET /demo/sleep.aspx?SleepTime=25, time:6339 msec, client:localhost)

You can get this from the command line (the new swiss army knife command line management tool - appcmd) or the IIS7 management UI. This is wicked cool, I now have a haystack to look for that needle :) I could filter by AppPool and/or couple this with PowerShell to get more filtering capabilities (e.g. top 5 most expensive time take queries).

Failed Request Tracing

The above is excellent...if you are at the console at the time of the issue. What happens when you get the call to fix a problem that happened last Tuesday at 2 am? Typical scenario! That's where Failed Request Tracing comes in (sometimes referred to as Failed Request Event Buffering or FREB). IIS.net does a good job detailing some aspects of Failed Request Tracing (check out the Vista work around for getting ASP.NET events). For the demo today, I setup the rule to trap any ASP.NET requests longer than 7 seconds.

This kind of proactive tackling of issues is sorely missing. Now with the rule in place, I can review requests failing my rules, e.g.

I'm able to see that this request (a typical location is C:\inetpub\logs\FailedReqLogFiles\W3SVC1), succeeded with a Status 200 but failed my rule by taking longer than 7000 msecs.

Instrumentation

If you look closely, the actual ASP.NET trace data (line 13 in our demo code) shows up in this Failed Request Log Entry - I now have a rich set of data to track down issues - even before they spiral out of control.