We measure end user experience using two complementary approaches: synthetic testing, which involves testing a website by simulating visitor requests; and real user monitoring (RUM), which involves watching actual user interactions with the site.
Basic synthetic testing of websites is easy to implement, and there are many free options available to operators of fledgling websites. It should be the first kind of performance and availability monitoring you deploy for any web application. While it can’t give you the granularity and accountability that comes from watching actual users, it offers peace of mind and an understanding of the percentage of time your site is online and how long it takes to retrieve specific pages.
In this chapter, we’ll look at some of the fundamentals of synthetic testing and how to leverage what you already know from your web analytics data to best configure synthetic tests.
The most basic distinction in synthetic testing is between internal tests run behind your own firewall and external tests run from locations around the Internet. While the bulk of this chapter will focus on synthetic testing done outside your data center by a third party, it’s important to understand the basics of internal testing to know what data you already have on hand and don’t need to use testing services for.
Internal tests are those you run within your own data center to ensure all of your machines are working properly. You can run simple, simulated transactions to each server to verify that everything’s working, as shown in Figure 9-1. Many web operators rely on commercial monitoring software, such as HP Sitescope, or open source tools, like Nagios, to do this.
Because you’re running your own test systems over a LAN connection with lots of spare capacity, you can afford to generate large numbers of tests every few seconds. This will give you more complete “coverage” of your website, since you’ll have smaller intervals between each test during which something can go wrong.
Internal testing is an essential tool for any IT operator. It may take the form of simple “Are you there?” up/down checks run every minute to each machine, or that of more comprehensive HTTP requests that check each machine’s response for the correct content.
For websites whose infrastructure includes a load balancer, a second—and increasingly common—option is to use this device to generate internal tests.
Load balancers provide redundancy by detecting server failures and taking the offending machines out of rotation. To do this, load balancers need to know when a server is broken. They determine this by running their own small tests, as shown in Figure 9-2. Since they’re already testing each server, you can use load balancers for monitoring—to a degree. While they’re good for up/down alerting, they won’t provide long-term performance baselines and trending, although some monitoring tools can extract test results from them and graph them over time using programs like Cacti (www.cacti.net/) or MRTG.
A load balancer can monitor the network, TCP, and HTTP services on the machines across which it is distributing traffic. Any health check sent to a server comes back as “working” or “broken.” Because they’re constantly sending traffic to servers, load balancers are often the first to know when a bad response comes back. Some go as far as to inject JavaScript into pages as they go past in order to extract performance metrics from user visits.
You should always run internal tests. The load balancer’s job is to hide broken servers from the outside world, and as a result, no external test will see a failed server when the load balancer is functioning properly. Internal tests fill in the gaps in your external monitoring, and because you run the tests yourself, you save money by reducing the number of external tests you need to pay for. However, internal device monitoring tools aren’t able to properly simulate your visitors’ conditions and shouldn’t be used as a substitute for external monitoring.