Chapter 18: Connectivity Performance

• Use benchmark sites or benchmark servers and sign up for third-party reports to monitor them as a way of evaluating the connectivity of the vendors on your short list.
• An SLA should include a clear definition of uptime in terms of what locations can or cannot reach your web site.
• If you know that access to your web site via certain ISPs or from certain locations is particularly critical, evaluate vendors on this basis and negotiate your connectivity SLA to reflect this requirement.
• Use packet loss as the next most important measurement (after user-perspective performance measurements) for evaluating a web-hosting service’s current ability to deliver web pages.
• Use latency as the third most important criterion for evaluating a web-hosting service’s ability to deliver web pages.
• Recognize that the effect of lost packets is not limited to just the retransmission time, but that they’re also used implicitly to reduce the effective speed of connections.
• Ask prospective vendors to show you their traffic and outage reports, or (even better) give you access to their real-time traffic graphs.
• Use Matrix.net’s free reports to gain a high-level perspective on the performance of major ISPs and web-hosting services. Reports are also valuable for evaluating the ISPs used by small and mid-sized web-hosting services.
• Use the Internet Health Report as a cross-check when diagnosing short-term (day or month) performance problems.

Chapter 19: Monitoring

• Keep your benchmark site running at your selected web-hosting service beyond the vendor evaluation period and throughout the lifetime of your web site.
• Use the measured performance of the benchmark site as the basis for your connectivity SLA.
• Measure the performance of your competitors’ web sites. Use this data before your site goes live to communicate your expectations both within your own company and to your vendors. Use it after your site goes live in order to see how responsive your web site is to your customers relative to the responsiveness of your competitors’ sites.
• Ask your prospective web-hosting service or MSP if it uses the notification capabilities of external services. If so, you should be able to get access to the reports and be added to the notification address list. If they don’t use such services (i.e., they depend entirely on their own monitoring systems), consider contracting for external monitoring yourself in order to track your web site and the responsiveness of your web-hosting vendor.
• Make sure that any monitoring system that tests your site’s response to HTTP requests, checks the accuracy of the returned content.
• Develop a special monitoring page on your web site, the content of which depends on as many of the internal components of your web site as possible. Use the monitoring system to test the generated content of the monitoring page as a means of verifying that the internal components are operating properly.
• Use the diagnostic capabilities of third-party monitoring tools to begin the problem determination process for performance problems.
• Ask prospective vendors to show you the internal monitoring systems they use. You should be able to get web-enabled access to view the status of your servers. If you’re using pure colocation, install such a monitoring system for yourself.
• Use the trend-reporting capabilities of internal monitoring systems to identify impending capacity problems. Compare this empirical data with the projections from the spreadsheets you developed in Chapter 11, Traffic Models.
• Make the real-time and trend reports from external monitoring available to your management team and perhaps to your entire organization.
• Don’t enable access to your reports until your web site has achieved some degree of stability.

Chapter 20: The Net Detective Toolkit

• Use telnet to send an HTTP “HEAD” command to competitors’ web sites to learn what software the sites are using.
• Use Netcraft to find out what operating system software a web site is running and how long the site’s web server has been up since last being re-booted.
• Use Netcraft to find out where a web site is hosted.
• Use Netcraft to learn the identities of some of a web-hosting service’s customers, possibly some that aren’t on the vendor’s customer-reference list. Contacting these customers could provide valuable information about the vendor.
• The Netcraft report of a web-hosting service’s 50 longest-running web sites may be an indication of the operating systems and web-server software packages with which a web-hosting vendor is most successful.
• Knowing the hardware and software platform a web-hosting service or MSP uses for its own site may provide insight into the vendor’s skills and preferences.
• Look for evidence of a web-hosting service or MSP’s upgrades to its own web site to suggest directions for further research.
• Use traceroute to gather evidence of a web-hosting service’s third-party relationships.
• Use the whois utility to discover who owns a network to which a router for which you only know the IP addressis connected.
• Traceroute and whois, used together, can help you identify tenant and reseller web-hosting services-those that depend on the facilities of other vendors.
• Use the Net Detective Toolkit as a way to identify customers of your prospective web-hosting services, MSPs, and CDNs. Communicating with these customers will be your most valuable source of information.
• Use third-party measurement and analysis tools as part of your evaluation of the effectiveness of content delivery networks.

Chapter 21: Domain Names and DNS

• Execute DNS changes by progressively reducing the TTL (time to live) on the associated records. After making changes and testing them, increase the TTL progressively in order to reduce the impact of any un-caught errors.
• Use at least two public DNS name servers. One of them should be operated by your web-hosting service or MSP, preferably on the same network as your web site. The other(s) should be on separate networks, and preferably operated by other business entities.
• Always register domain names yourself. Never create a web site under a domain controlled by someone else.
• Don’t, under any circumstances, register or transfer a domain using an organization not on the ICANN-accredited list.
• Investigate your registrar’s policies regarding who’s allowed to modify your domain name registration. Be aware that some registrars permit any named contact to make changes.
• Always use email aliases for domain registration contacts.
• Use handles to centralize the management of contact information.
• Make domain name registration contact changes one at a time in order to preserve an escape route in case you make a mistake.
• Use password or PGP authentication to protect domain-name registration transactions. Don’t give your vendors the passwords or keys, and never depend on email authentication alone. Keep copies of your passwords or keys in a safe place. It’s very difficult to make changes without them.
• Add your web-hosting service, MSP, and CDN to the email alias for your domain registration Technical Contact. You also may want to list their NOC phone numbers. But don’t list them by name or give them passwords or keys that would allow them to change the registration.

Got another tip you think we should add to the list? Email it to tips.