The Well-Tuned Server, Part 2by Mitch Tulloch, author of Windows Server 2003 in a Nutshell
In a previous article, I looked at tuning file servers by implementing disk quotas. In this second part of a two-piece article on tuning servers, I'll cover how to fine-tune your web servers. I'll show you five quick ways you may be able to enhance the performance of machines running IIS 5 (Windows 2000) and IIS 6 (Windows Server 2003).
I say may enhance because success in tuning IIS also depends on how you use it (corporate versus hosting environment, dedicated- vs. shared-server roles) and what applications you run on it (static vs. dynamic content, single vs. multi-tier). I'll focus here on tuning methods that apply generally across a wide range of applications and environments. For additional information on tuning IIS performance see my books, Administering IIS 5 and IIS 6 Administration.
IIS lets you control its usage of network bandwidth in two ways: globally (bandwidth used by all web sites on your server) and on a per-web-site basis. Global throttling is configured on IIS 5 using the Internet Information Services tab of the
Server_Name properties sheet in Internet Service Manager (ISM). On IIS 6 use the Performance tab on the Web Sites properties sheet.
Throttling bandwidth used by individual sites is configured on both platforms using the Performance tab of the
Web_Site_name properties sheet (see Figure 1).
Figure 1. Configuring bandwidth throttling on IIS 6.
Global throttling is useful if your server also has other roles like file/print server or mail server that compete with IIS for use of your network adapter. Per-site throttling is helpful if you host multiple web sites on a single server, especially in a hosting environment where each web site is owned by a different company (your other clients would be pretty upset if one client hogged all the bandwidth). Note that when you throttle on either a per-site or global basis, you only limit the amount of bandwidth for IIS; it doesn't affect other network services like the Server Service.
Per-site throttling overrides global throttling, so you can ignore the global setting if you are throttling bandwidth at the site level. Throttling only works for static content (.htm files and images) and doesn't work with IPv6 as your network transport. Throttling requires that you install the QoS Packet Scheduler service on all network connections. (On Windows Server 2003 this is done automatically when you enable bandwidth throttling at the global or site basis, but on Windows 2000 you have to do this manually by opening the Local Area Connection properties sheet and selecting Install-->Service-->Add-->QoS Packet Scheduler). And the default setting of 1024 kilobytes/sec is there for a reason --anything less at the global or site level and bandwidth throttling doesn't work.
Note that if you're hosting several sites and you want one of them to have essentially unlimited bandwidth, how you do this depends on your global-throttling setting. If global throttling is turned off, simply clear the checkbox in Figure 1 for the favored site to allow it unrestricted bandwidth usage. If global throttling is turned on however, leave throttling enabled on the favored site and specify a high value for the site's maximum bandwidth (the highest value you can specify is 32,767 kilobytes/sec and if this isn't enough then edit the metabase to set
MaxBandwidth equal to
-2 for that site).
How do you know bandwidth throttling is working? Users start complaining about getting HTTP 500 Internal Server Error messages. If that happens a lot you've probably configured your settings too aggressively.
IIS also lets you limit the amount of CPU cycles an individual web site can use. On IIS 5 this is again configured on the Performance tab of the web site's properties sheet, but on IIS 6 running in worker-process isolation mode you use the Performance tab of the properties sheet for the application pool to which the web site belongs (you can also configure this setting globally for all application pools, though you can override this for individual pools).
Figure 2. Configuring process throttling on IIS 6.
Figure 2 shows the Performance tab for the
DefaultAppPool in IIS 6 (this application pool contains the Default Application, which corresponds to the Default Web Site). Process throttling is turned on for the pool by selecting the "Enable CPU monitoring" checkbox and this tracks the CPU usage of worker processes servicing the pool. To monitor CPU usage you can configure both a maximum usage (in percent) and a refresh interval (in minutes). When the maximum is exceeded one of two things can happen: an event is written to the event logs (No action) or an event is written and worker processes are recycled (Shutdown).
On IIS 5 the approach is basically the same: enable process throttling, specify the limit in percent, and select "Enforce limits" to force a shutdown of a hyperactive application.
While bandwidth throttling is only effective for static content, process throttling is intended mainly for dynamic content (with the exception of CGI applications for which it doesn't work). On IIS 5 process throttling only works for out-of-process applications, but on IIS 6 all applications generally run isolated in application pools (unless your server is running in IIS 5 isolation mode where it mimics the architecture of IIS 5).
On both platforms you can also control the number of HTTP clients that can connect to each web site. The settings here include limiting the maximum number of connections (unlimited by default), specifying a timeout interval for disconnecting idle clients (120 seconds by default), and using
HTTP Keep-Alives to keep TCP connections open across multiple HTTP requests (enabled by default). On IIS 6 the connection limit is specified on the Performance tab (see Figure 1 again) and the remaining settings on the Web Site tab (Figure 3), while on IIS 5 all three settings are on the Web Site tab.
Figure 3. Configuring connection timeouts and HTTP Keep-Alives on IIS 6.
Connection limits are especially useful when web servers also have other roles, as they prevent IIS from hogging all the connections and preventing clients from accessing other services on the servers. When configuring connection limits, figure on four concurrent TCP connections per HTTP client, so if you expect no more than 50 clients simultaneously connecting to your server, set the limit to at least 200 connections.
At the very least, change the connection timeout from
Unlimited to the default value of
1000 that IIS suggests, as leaving it set to
Unlimited increases your server's exposure to denial-of-service (DoS) attacks (this is one case where Windows Server 2003 is not out-of-the-box secure). And be sure to leave
HTTP Keep-Alives turned on, since all browsers from IE 4.01 onwards support it.
IIS can also compress HTTP traffic to increase throughput, a feature that can be useful if your clients support it (IE 5.0 or later). HTTP compression works for both static and dynamic content, and on IIS 5 it's enabled on the Services tab of the WWW Services Master Properties sheet. On IIS 6 you use the Services tab of the Web Sites properties sheet (Figure 4).
Figure 4. Enabling HTTP compression on IIS 6.
Use compression with care, especially when compressing dynamic content, as it compresses each page each time it is requested. As a result, dynamic compression will help you save network bandwidth at the expense of considerable additional CPU and memory usage. This doesn't happen with static content as compressed files are cached.
Compression looks simple in the GUI, but if you dig into the metabase on IIS 6 there are a whole pile of ways you can tweak it, including specifying which file types are compressed, which compression scheme (gzip or deflate) to use, level of compression, and so on.
Finally, be aware that IIS logging can generate a ton of disk activity and slow down your processor, especially if you are using W3C Extended log file format (see Figure 3 again) and have a lot of extended logging options selected (Figure 5).
To keep your server from slowing down (or running out of disk space and grinding to a halt) make sure you log only the essentials useful to you for tracking usage or monitoring security for your web servers. In most cases this means logging only the default log items like Date, Time, Client IP Address, and so on. Logging other items like Bytes Sent, Time Taken, or Referrer are usually only enabled for troubleshooting purposes or security reasons.
Figure 5. Extended logging options for W3C Extended log file format.
Return to WindowsDevCenter.com.
http compression works pretty well too
2006-01-06 15:15:02 ServeThis! [View]
- Trackback from http://blog.dannyboyd.com/archive/2004/02/19/213.aspx
The Well-Tuned Server, Part 2
2004-02-19 17:47:37 [View]
- Trackback from http://blog.lotas-smartman.net/archives/001408.php
The Well-Tuned Server, Part 2
2004-02-18 00:41:19 [View]