Diagnosing Server Slow Downs

Posted: December 28th, 2010
Filed under: Web Speed and Performance

If your web server is experiencing performance slow downs, and in particular if the average load time of your pages seems to be increasing, a good first place to check for what might be causing the slowdown would be your IIS logs.

If 304s constitute a large proportion of the responses in those logs, then an expiration-based cache control solution like CacheRight can help to reduce the need for these requests from browsers, freeing up server resources to serve actual content to users that need it.

Side Note: If the problem is not excessive 304s but just an increase in the number of 200OKs, then compression (e.g., httpZip) might be a more effective remedy for the performance lag.


In order to tell if CacheRight will help speed up your users’ page load times, we’ve written a little script for use with Microsoft’s Log Parser tool (which itself is free). The following script contains a SQL query you can run against your IIS log files, to determine the proportion of 304s to other responses:

SQL Query to enumerate requests in IIS Log File by response code.

SELECT sc-status AS StatusCode,
COUNT(*) AS NumberOfHits
FROM %inputfile%
GROUP BY StatusCode

To run this query you will need to download Log Parser 2.2.

Just copy the above script into a text file and save it with a .sql extension. You will want to open a cmd window and change to a current working directory that contains all of the following:

  • Your .sql script file
  • Logparser.exe
  • All of IIS log files that you want to include in the analysis

Here is the syntax to execute the .sql script on the command line (assuming you called the file myscriptfile.sql):

logparser file:myscriptfile.sql?inputfile=ex*.log > outfile.txt

When you run this, the resulting output file (outfile.txt) should contain a simple table enumerating how many HTTP responses of each type (200, 302, 304, etc.) were found in your IIS logs.

As simple as this script is, it really contains the key metric for determining if you can benefit from CacheRight (that is, from expiration-based cache control).  Here is an example of the type of output you might see if you have a situation where CacheRight can help (the exact numbers aren’t important, just the proportions):

StatusCode NumberOfHits
———-       ————

304        751762
200        301112
302        32932
404        2132
400        1456
500        687
206        243
301        14


Elements processed: 933293
Elements output: 8
Execution time: 6.37 seconds

Based on the above sample data, it’s clear that this server could benefit from being relieved of the burden of having to send so many 304 Not Modified messages. As you can see, there are many more 304 Not Modified responses than 200 OK responses.  What this means is that the server is using far more of its available resources just to tell browsers to use the cached copies of files they already have, than to actually send them new content that they need.

In this case, implementing expiration-based cache control on static dependencies like images and JS and CSS files (which is what CacheRight does best) should greatly reduce the proportion of 304 responses that the server has to issue. That would free up those resources to serve content that actually needs to be sent afresh.

And keep in mind that doing expiration-based cache control will also let browsers use most files directly from their local caches, without having to revalidate them by issuing these requests to the server and waiting for the 304 responses to come back.  Since the 304s represent files that were in fact fresh at the time the requests were made (after all that is what a 304 response means), the 304 count is really a measure of the total number of unnecessary round trips that return visitors’ browsers are having to perform before the pages they are viewing can be completely rendered.  And more round trips mean slower-loading pages.

So how low should you want your 304 count to go? While a certain number of 304s is normal and desirable, you should ideally aim to get the proportion of down to something under 10% of the total number of 200 OKs. Anything above that, and you’re likely wasting perfectly good server and network resources, and quite literally <em>making your users wait for nothing</em>.

So check that 304 count! You may just find that implementing proper cache control is quick-and-easy way to improve both your site’s page load times and your server’s traffic-handling capacity.

No Comments »

Comments are closed.