Today I took the unusual step of intentionally slowing down my site. I wanted to evaluate how the various web server monitoring services responded to this issue.
I maintain the site using Drupal, which has some great OOTB cache settings, including:
- Cache pages for anonymous users
- Cache blocks
- Compress cached pages
- Aggregate and compress CSS files
- Aggregate JavaScript files
Around midnight, I turned all these settings to the wrong values and watched the fun begin. I logged into WatchMouse, one of the higher end services that tracks response time. As expected, we observed an increase in page load time, especially in the processing time, shown in green below.
As of noon today, other services did not appear to have same-day data available in graph format. For a rough comparison, I pulled yesterday's response time graphs where available.
In a manner similar to WatchMouse, Hyperspin breaks down its response time graph into phases:
- DNS resolution
- Connection
- Request
- Processing
- Download/Response
However, Hyperspin only averages the stats over the selected time period.
Dotcom-Monitor shows response over time, but it does not break down the components of an HTTP request. It has fewer data points in this graph because it was configured to run a test every four hours.
Pingdom charted the same data, although with more detail.
While setting up this test, I cleaned up the home page and removed the OOTB Drupal login box for non-logged-in users. The site is not focused on membership right now, and ithe box ate up a lot of screen real estate.
AlertFox quickly reminded me that I had set up a transaction monitor to attempt a login from the home page. This will sound familiar for any developer who's familiar with automated tests. If you change the code (or website), you must change your test. Here's what that looked like in AlertFox.
Comments
Add new comment