Web Server Traffic
The amount of traffic your Web server handles is probably the best indicator of how hard that server is working. Although you can define traffic in different ways, I define it as the number of requests per second the Web server handles—not the number of connections to the Web server. Because this definition is controversial, I want to take a minute to explain why the number of requests per second is a better indicator of server load.
When a user types in his or her browser a URL for a location on your Web server, the browser opens a connection to the Web server and requests the Web page. When the browser receives the page, it might close the connection, reuse the connection, or open several more connections to request JavaScript, images, and Cascading Style Sheets (CSS) from the Web server. After the browser fully renders the page, the connection might remain open, but the Web server doesn't need to do any work while the user reads the page. The open connection doesn't require the server to work; the server works only while it handles requests. In fact, TCP connections aren't persistent, and the server doesn't have to work to maintain an idle connection—it just stores some connection information in RAM.
Thus, I recommend watching the Web Service object's Get Requests/sec counter. It's a better traffic indicator than the object's Current Connections counter. Get Requests/sec tells you how many GET requests the server is handling at a particular second. If your site is POST heavy, you can also look at the Post Requests/sec counter. The Last field is interesting, but to gauge your traffic, you should look at the Average field. As a reference, most Web servers aren't really working until they average more than 50 requests per second. If your Web server can't handle this number of requests, you need to look for threading or program bottlenecks. Well-tuned servers can process more than 250 requests per second on average. Continuous traffic at 50 requests per second amounts to 4.32 million requests, or hits, per day.
You can also monitor the number of bytes the Web server sends and receives. A GET request is typically 100 bytes to 500 bytes; a POST request can be much bigger. Use the Web Service object's Bytes Received/Sec and Bytes Sent/Sec counters and the Average field. Keep in mind that a 10Base-T LAN's maximum throughput is about 9Mbps, or 1.125 MBps; don't expect your Web server to exceed your network limits.
Another useful Web Service object counter is Service Uptime, which you can use with a Web site instance that you specify to report the number of seconds that a Web site has been up. You can use the Service Uptime counter to check whether IISreset (which ships with Internet Information Services—IIS—5.1 and IIS 5.0) or some watchdog utility restarted the Web site in the middle of the night.
ASP
When you add the Get Requests/sec counter, the Performance tool tracks all the requests for ASP and ASP.NET pages, images, CSS, JavaScript files, downloads, and everything else on your Web server. ASP pages require considerably more processing power to serve than static files do, so you might want to monitor them separately. To do so, add the Active Server Page object's Requests/sec counter. (If you're running ASP.NET, use the same counter and the _Total instance under the ASP.NET Applications object.) The Requests/sec counter can help you identify the existence of threading bottlenecks and help you determine your ASP pagetostatic page ratio. For example, if the server is handling many ASP requests at the same time but the Requests/sec counter shows only one request, you might have a threading bottleneck.
Static Files
IIS has a RAM cache that stores the most recently used static files. (You might not even know this cache exists because it doesn't require any administration.) New in Win2K are performance counters for monitoring this static-file cache. You can use registry settings to store more files, make the cache bigger, or lengthen files' Time to Live (TTL) value.
If you think you might want to change one or more of the registry settings, monitor the cache for a while first to determine how it works. You can use the Internet Information Services Global object's Total Files Cached counter to find out how many files are in the cache. Although you can't force files into the cache, you can tune your Web server to allow more files in the cache. IIS serves cached files faster, so the more files in the cache, the better.
The Internet Information Services Global object's Maximum File Cache Memory Usage counter tells you how much RAM is devoted to the file cache. On machines that have a lot of RAM, assign more RAM to the cache so that it can handle more files.
The Performance tool is a great way to get a handle on what your Web services are doing. The Web Service, Active Server Page, and Internet Information Services Global objects have a lot of great counters to track your Web server. As you run these counters on your servers and gain experience with them, you'll be able to tell at a glance how well your systems are performing.