Useful LogParser Queries

If you deal with production servers and you don’t use LogParser, you should. It gives SQL-like abilities to query web server logs an other log types (like Event Logs). Coding Horror has a great article about the tool as well, and a link to a good article about forensic log parsing. Here are my most used web queries:

Find Pages with 500 errors
logparser "SELECT cs-uri-stem as Url, sc-status as code, COUNT(cs-uri-stem) AS Hits FROM C:\ProdLogFiles\ex*.log WHERE (sc-status >= 500) GROUP BY cs-uri-stem, code ORDER BY Hits DESC" -o:CSV >> C:\Data\ErrorPages.csv

Find 404 Requests
logparser "SELECT cs-uri-stem as Url, sc-status as code, COUNT(cs-uri-stem) AS Hits FROM C:\ProdLogFiles\ex*.log WHERE (sc-status = 404) GROUP BY cs-uri-stem, code ORDER BY Hits DESC" -o:CSV >> C:\Data\404Pages.csv

Find the Slowest Pages
logparser "SELECT TOP 100 cs-uri-stem AS Url, MIN(time-taken) as [Min], AVG(time-taken) AS [Avg], max(time-taken) AS [Max], count(time-taken) AS Hits FROM C:\ProdLogFiles\ex*.log GROUP BY Url ORDER BY [Avg] DESC" -o:CSV >> C:\Data\SlowPages.csv

Posted: Thursday, August 06, 2009 7:41:00 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
ASP.NET | IIS | Performance | Tools

ASP.NET 404 Errors on the Default.aspx Page

On a new server install, you can copy over the files for your web app and mysteriously get 404 errors. It's a simple configuration in IIS. By default the server is configured not to allow ASP.NET. You simply need to enable this in the IIS management console:

Posted: Wednesday, August 29, 2007 11:36:10 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
ASP.NET | IIS

Caching Images in IIS 6.0

Yahoo posted a list of rules for improving the performance of your web site, along with a new FireFox-based tool for diagnosing your site's performance, called YSlow.

Their number one rule is to reduce the number of HTTP requests, and this only makes sense. I'll bet most of us ASP.NET developers are well aware of output caching, and how to do this in code. But what about those static files, like images and scripts? Well, there is an IIS setting for that. It's easy to do, and the payoff can be big if you have a very graphic-intense site. Here's what you do for IIS 6:

  1. Open the IIS Management console
  2. Find the directory containing your images (static content only)
  3. Right click the directory, and choose Properties.
  4. Click the HTTP Headers tab.
  5. Check the Enable Content Expiration check box.
  6. Click the Expire After radio button, and choose an interval.
  7. Click the OK button. Done!

The downside is that you won't get the payoff for the first time a user visits the site, but other pages using the same resources will be much snappier. Be aware that caching dynamically created content this way can cause some strange issues, so take care as to what you cache. As always, test it well before you release it and you will be rewarded.

Posted: Monday, August 20, 2007 4:11:05 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
IIS | Performance

Awesome IIS Resource

IISToolshed - thanks to Paschal for pointing it out.
Posted: Thursday, December 01, 2005 7:23:36 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
IIS

SelfSSL and Site ID

SelfSSL is a tool found in the IIS 6.0 Resource Kit. It allows you to generate SSL certificates for a development environment. In all the instructions for using SelfSSL, it describes one of the parameters as "Site ID", where the default value=1, which is the default web site installed on the computer. The Site Id parameter is essentially telling SelfSSL which web site to install the certificate into. Well, if you have multiple web sites, then the default site id is useless. You need the Site Id of the web site where you want the certificate installed. Of course the documentation does not spell this out, and as a non-Admin the Site Id was not an intuitive term for me. But I found that there is a script you can run from the command-line called iisweb.vbs using the /query switch. That will tell you the Site Id. Seeing that, then I realized that the IIS log file folders (in windir\System32\logfiles\) are named according to the Site Id.

Anyway, creating a second certificate for a different site on the same IIS using SelfSSL messes up the SSL cert of first site. This is a known issue apparently, and David Wang has a great post on this problem. The comment further down by Paul Carrig is most useful, as he points out there is a workaround for the SelfSSL and multiple site issue. So I actually found two workarounds:

  1. The technique described by in the aforementioned post:
    1. Install the cert in the first site
    2. Export it to a .pfx file
    3. Install the cert in the second site
    4. Remove the cert from the first site
    5. Re-Import the cert to the first site using the .pfx file

      or
  2. Install the cert in the first site, and export it to a .pfx file. Then import that to the other sites. The down side to this is that the certificate is even less valid for the second sites as now it has an untrusted publisher (me!) and the site name is not a match. The prompt is essentially the same, but in our case one site contains web services which will throw an error if the prompt comes up at all (as it should). The workaround for that is to install the certificate on the client computers as well, which is an acceptable problem for a development enviroment.
Posted: Monday, August 08, 2005 8:27:20 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
IIS | Security