Whether you administer a small, corporate intranet or a high-bandwidth Internet site, knowing how to optimize Microsoft's Internet Information Server (IIS) Web server software can affect the success of your project. Microsoft released IIS 1.0 in early 1996 as an add-on to Windows NT Server 3.51. Since version 1.0, IIS has grown into a stable, scalable environment for intranet and Internet Web-serving. NT ships with IIS 2.0. (For more information about IIS 2.0, see Stephen Genusa, "Serving Up Internet Information," October 1996, and the Windows NT Magazine Lab's "Web Server Software Roundup," September 1996.) Microsoft recently released IIS 3.0, which includes the Active Server Pages execution environment that lets you run ActiveX Scripts and ActiveX Server Components on the server. You can download IIS 3.0 from Microsoft's Web site at http://www.microsoft.com/iis. Although much of IIS is self-tuning, the product provides configuration options that you can use to tune IIS for maximum throughput. Most IIS configuration options are available through the IIS administrative interface, Internet Service Manager, but some require changes to the NT Registry. Let's look at several tips for optimizing IIS performance.

Tip 1:
Choose the Right Server Hardware and Configuration

Pentium-based servers will perform well as IIS servers. IIS runs on MIPS, PowerPC, and Alpha processors, but these machines are more expensive, and Intel versions usually are released before other platforms' versions.

Determining the proper amount of memory depends on what other applications you plan to run on the server. If IIS is the only application, 32MB is probably enough memory. However, if you plan to run other applications such as SQL Server or connect to other databases via Open Database Connectivity (ODBC), you'll need a minimum of 64MB of memory for optimal performance. Disk space will vary depending on the size of your Web site. After installing IIS, you can use NT's Perfmon to help determine the proper hardware requirements to locate any bottlenecks in the system, such as processor utilization, network throughput, and disk access times.

Tip 2:
Use Fast Internet Connections

As with any Web server, IIS's performance depends heavily on the speed of your Internet connection. To attach your site to the Internet, an Internet Service Provider (ISP) provides you with a network cable. In the US, these leased connections vary in speed from 56Kbps (with Integrated Services Digital Network--ISDN--or Frame Relay) to 45Mbps (with a T3 connection). Small IIS sites need at least an ISDN Basic Rate Interface (BRI--64Kbps to 128Kbps) on an Ethernet or Token-Ring backbone. Anything less than ISDN on even a small site with a couple of users will quickly consume all your bandwidth and slow download times to a crawl. Large sites, such as Microsoft's, have up to eight 45Mbps T3 lines on 100Mbps Fiber Distributed Data Interface (FDDI) backbones to support millions of daily connections.

Tip 3:
Set Up the System as a Standalone Server

When you install NT Server, you can designate it as a Primary Domain Controller (PDC), Backup Domain Controller (BDC), or standalone server. For maximum IIS performance, set up your IIS server as a standalone server dedicated to performing only IIS functions, so it doesn't use additional system resources to perform network logon requests. If you have multiple servers, let the server participate in a domain but not as a domain controller. This way, you can distribute user accounts among the servers in the domain for easier access control and administration.

Tip 4:
Use NT Server's DNS Round-Robin Feature

A great addition to NT Server 4.0 is the new Domain Name System (DNS) service. The graphical interface will shave hours off setting up a new DNS server and let you manage multiple servers from one interface. To help your site accommodate future processing needs and increasing Internet/intranet traffic, NT's DNS service performs a round-robin function. An administrator can add a series of identical A (host) records in Domain Name Service Manager to create a pool of addresses pointing to different physical servers. This virtual router approach lets you distribute the processing and traffic load across multiple servers, while providing a fault-tolerant environment in case one server fails.

To create a round-robin pool, add new host records ( i.e., www and ftp records) in NT's Domain Name Service Manager for each server and IP address. Screen 1 shows a sample round-robin pool. After adding the records, you can use the ping command with the host name to display an alternating pool of addresses (more about ping in Tip 11).

When you use the round-robin approach to distribute network traffic across multiple servers, you also face synchronizing the peer servers' content. Content is the data available on your IIS server and can include HTML, FTP, or Gopher files. Synchronization methods include using FTP, batch processing, or directory replication to distribute the same content to your Web servers. Microsoft's latest NT content-distribution solution is the Content Replication System, which is part of Microsoft's Com-mercial Internet System (CIS­previously Normandy). CIS is a suite of applications including Conference Server, Personalization System, and Merchant Server. Designed as a fault-tolerant, scalable solution, the Content Replication System can distribute and synchronize data across a range of network sizes--from small LANs to large global information networks with dozens of distribution servers. Microsoft plans to release the Content Replication System in the second quarter of this year. You can find more information about it and other CIS components at http://www.

Tip 5:
Use NT's Disk Defragmentation

Another way to help IIS perform better is to use a third-party disk defragmentation utility, such as Executive Software's Diskeeper or Symantec's SpeedDisk. In NT 4.0, Microsoft added disk defragmentation code to the Win32 API to eliminate file fragments and reduce the amount of disk access by the operating system. File fragmentation occurs when files on a disk are not contiguous but are broken up and scattered at different physical locations on the disk. Defragmenting can substantially boost performance, especially on servers with many relatively small files--typical for Web servers. Diskeeper is available for both NT 3.51 and 4.0, but SpeedDisk requires NT 4.0. Both utilities have a lot of features and can operate as background applications. (See page 50 for a review of Diskeeper.)

Tip 6:
Use IIS 2.0 or 3.0

IIS 2.0 and 3.0 are much faster than IIS 1.0 and include many enhancements. Microsoft claims that versions 2.0 and 3.0, which both require NT 4.0, are 40 percent faster than IIS 1.0. A comparison rating of these versions is available at http://www.microsoft.com/iis.

Tip 7:
Change IIS Log and Bandwidth Settings

Internet Service Manager, IIS's graphical administration interface, includes two properties that affect IIS performance: the log settings and the bandwidth setting. When configuring IIS logging via Internet Service Manager, you can either log to a file (network connection information is written to a file) or log to an ODBC system data source (connection information is written to a database); file logging is faster.

When file logging is in effect, IIS receives connection requests and stores them in a memory buffer with a default size of 64KB. You can change this size in the Registry: the higher the setting, the less disk activity for logging (filling the buffer takes longer) and thus, better performance. If you want more realtime logging information at the expense of performance, you can lower the setting, causing the buffer to flush more frequently. When you shut down the server, the information in the file-logging buffer is flushed to disk so that log data isn't lost. (For information about file logging, see Microsoft's Knowledge Base article Q142557, available via http://www.microsoft.com or Microsoft TechNet.)

You can set log file buffer size in the Registry's HKEY_LOCAL_MACHINE hive as follows:




Subkey: LogFileBatchSize

Be careful when you make changes to the Registry; an incorrect entry can prevent the machine from booting or force you to reinstall NT. (For information about setting the log file buffer size and other IIS Registry settings, see Microsoft's Knowledge Base article Q143180.)

Another way to obtain realtime connection information is by logging to an ODBC data source. Logging to an ODBC database such as SQL Server or Access writes connection data to the database in realtime, so the data is always current. Of course, this approach greatly slows system performance and throughput. If you don't require realtime data, use file logging and raise the buffer level to decrease disk activity.

The second important property in IIS's Internet Service Manager is the bandwidth throttle, located under the Advanced tab on the WWW Service Properties dialog box (as shown in Screen 2). By default, this parameter is turned off so that all IIS services have access to the maximum available bandwidth. Sites running a small intranet can lower the throttle setting to prevent IIS from consuming all network resources or possibly overloading slower bridges or routers. For example, a typical small, corporate intranet site running on Ethernet can reduce this value to 1024 to ensure that IIS services consume no more than 10 percent of available bandwidth. Sites dedicated to providing Internet services must keep this throttle disabled to transmit data at the maximum bandwidth, and ensure the best Web server performance.

Tip 8:
Change the MemoryCacheSize Registry Setting

Most Registry settings are self-tuning, but you can adjust the MemoryCache
Size setting to improve IIS perfor-mance. MemoryCacheSize caches all file handles, directory listings, and large binary objects; by default, it's set at 3MB. Sites with many files can set MemoryCacheSize to a higher value, depending on available system memory. You must use the Registry editor to change the MemoryCacheSize value (for more information about setting the memory cache size, see Microsoft's Knowledge Base article Q143180).

NT Perfmon includes a powerful tool to help determine whether your MemoryCacheSize setting is adequate. After starting Perfmon, locate the IIS Global object (as shown in Screen 3). Set the counter to Cache Misses to analyze the number of times a file open, directory listing, or binary object request was not found in the cache. A high number of cache misses means IIS is spending valuable clock cycles looking for objects; a low number means your cache is effective at the present value. Other Internet Information Services Global Object counters let you analyze the amount of cache in use and the cache's effectiveness.

Tip 9:
Use SSL Encryption Sparingly

The Secure Sockets Layer (SSL) data security protocol encrypts information as it travels across the Internet; IIS lets you use SSL encryption via the SSL Key Manager. The information you send across the Internet is transmitted as clear text. Thus, a hacker can easily intercept TCP/IP packets, reassemble them, and read the information they contain.

You can use IIS's SSL encryption, but be choosy about what you encrypt (for information about using IIS's SSL encryption, see "Serving Up Internet Information"). Force a Web browser into SSL mode only when you're retrieving data that must be encrypted for security reasons, such as credit card numbers and personal information. (You can tell when your browser is in secure mode; look for a lock-key icon in the lower right corner of Internet Explorer or Netscape Navigator.) Don't encrypt large objects such as graphics files; this process can create a substantial overhead for both Web server and browser.

Tip 10:
Convert CGI Executables to Runtime DLLs

The Common Gateway Interface (CGI) lets you add dynamic, or interactive, content to Web pages. CGI acts as a gateway between a browser and other applications, such as SQL Server databases. This gateway is an executable file that accepts environment variables via a default stream file interface called standard input (stdin) and returns the processed request through the standard output interface (stdout). A new process is created, executed, and terminated for every request. This interface increases processing time and requires large amounts of server memory.

A more efficient alternative to CGI is to convert existing CGI executables into runtime dynamic link libraries (DLLs)--
compiled, linked-function libraries that you can load during runtime. The advantage of using runtime DLLs is that you can load them into the same memory address space as IIS and run them under the same process as the HTTP server. Runtime DLLs make IIS's response time quick because the server doesn't have to create, execute, and remove a process from memory for every request it receives.

IIS lets you preload certain DLLs--ActiveX components (formerly called OLE Automation Servers)--to speed response time and unload others to conserve server resources. You can create ActiveX components in several programming languages, including Visual Basic 4.0 Professional and Enterprise Editions, Delphi, and Visual C++. (For information about creating ActiveX server components, see Module 3 of the tutorial documentation that ships with IIS 3.0.) You must code carefully and use adequate error handling when using runtime DLLs or ActiveX components in a program. Programming errors can lead to performance degradation or even IIS crashes. Thoroughly test and debug complex ActiveX components before putting them into production.

ou can improve IIS's performance by tuning TCP/IP, the protocol that Web servers communicate with. Tuning TCP/
IP is especially important if your site is interconnected via multiple servers with separate IP addresses; tuning helps reduce the time servers take to determine communication paths. Tips 11 and 12 work only in environments with static IP addresses; that is, the IP addresses assigned to the servers are dedicated, and the servers don't use Dynamic Host Configuration Protocol (DHCP) or BOOTP to obtain addresses during the boot process.

Tip 11:
Permanently Cache MAC Addresses

The starting point for optimizing TCP/IP is to cache the Media Access Control (MAC) address of the destination host computer (the MAC address is the unique address that the manufacturer burns into a LAN adapter). When the IP stack encapsulates a data packet destined for another host computer, it must know the MAC address of the packet's destination. TCP/IP uses the Address Resolution Protocol (ARP) to determine the MAC address associated with a specific IP address.

Before you can cache a destination MAC address, first use ping to make sure the destination system is connected to the network. At the command prompt, enter

ping hostname
ping IP address

If your server and the destination host are properly connected to the network, from the destination host, you'll get a response similar to the following:

Pinging with 32 bytes of data:
Reply from bytes=32 time<10ms TTL=128
Reply from bytes=32 time<10ms TTL=128
Reply from bytes=32 time<10ms TTL=128
Reply from bytes=32 time<10ms TTL=128

TABLE 1a: Displaying the MAC Address
for an IP Address
Interface: on Interface 2
Internet Address Physical Address Type 00-aa-00-3b-3b-e7 dynamic 02-07-01-19-d5-56 dynamic

Next, to determine the MAC address associated with a specific IP address, use the ARP utility. Enter

arp -g

at the command prompt to display the information shown in Table 1a. The MAC address of node has a physical hardware address of 02-07-01-19-d5-56. If the IP address had been on a different subnet, the hardware address would be the address of the router linked to the destination host, not the host. The type is dynamic, which means node's MAC address will be flushed from the cache if not used again within 2 minutes. Otherwise, it will still be flushed after 10 minutes.

TABLE 1b: A MAC Address Permanently
Stored in the ARP Cache
Interface: on Interface 2
Internet Address Physical Address Type 00-aa-00-3b-3b-e7 dynamic 02-07-01-19-d5-56 static

You can configure the time a MAC address is stored in the ARP cache (called cache aging) in the Registry (you need NT 3.51 with Service Pack 4 or NT 4.0). The ARP cache is a small section of memory in which TCP/IP stores IP addresses and their associated MAC adapter addresses. Because the ARP cache is always the first place ARP looks to resolve an IP address, permanently storing these entries in the cache prevents the server from having to send a broadcast packet to resolve IP addresses. This process eliminates wasted (i.e., broadcast) packets and improves network communications by producing packets directed only to a specific address rather than the entire network. You can permanently store the MAC address in the ARP cache by using the -s parameter, as follows:

arp -s 02-07-01-19-d5-56

The -s parameter stores the MAC address in the cache permanently, or until you restart the machine. After adding the MAC address into the cache permanently and then entering the command

arp -g

you'll notice the type is now static: The MAC address won't be flushed from the cache, as Table 1b shows.

To boost performance and reduce the number of broadcasts, cache the MAC addresses of host computers the IIS server regularly interacts with, such as SQL Server databases on different host systems. Permanently caching certain addresses minimizes server-to-server communications time--the amount of time a server takes to process a user request, execute the request (which may involve communications with other servers such as SQL Server databases), and return a response to the user.

Tip 12:
Adjust TCP/IP Window Size

Adjust the TCP/IP window size to tune TCP/IP and improve IIS performance. Microsoft's implementation of TCP/IP uses an algorithm called sliding windows. Sliding windows transmit a specific number of packets defined by the window size (the default is 8) and wait for an acknowledgment (ACK) from the destination host. When it receives packets, it sends an ACK to notify the source host about which packets it received. If the destination host didn't receive a particular packet--for example, packet 5 of the eight packets sent--the source host slides the window (number of packets to send) to packet 5, which then releases packets 9 through 12. The server waits until a timeout period expires to retransmit packet 5. The window won't slide past packet 5 until it receives an ACK for packet 5. This method ensures delivery of all packets across unreliable networks such as the Internet.

For a multiserver Web site that's clustered on one physical LAN segment, increasing the TCP/IP window size can be especially beneficial because it puts more data on the physical layer, thus shortening the ACK wait time. Increase the window size only when communicating across reliable networks, such as a LAN. Sites located across one or more routers must keep the default window size of eight because the routers could drop packets, causing the source host to wait to determine whether to retransmit packets. You can configure the default window size in the Registry (for information about setting this entry, see Microsoft Knowledge Base article Q120642).

Tip 13:
Use Analysis Tools

You can analyze your IIS server's performance with a tool such as WebStone 2.0, the current industry standard for measuring Web server benchmark performance. Developed by Silicon Graphics (SGI), WebStone is available for NT and UNIX platforms. You can download it for free from http://www.sgi.com. WebStone lets a series of clients simulate hundreds or thousands of requests over a configurable amount of time. You can configure WebStone to request straight HTML, CGI, or Internet Server API (ISAPI) applications.

To further fine-tune NT server operations, take advantage of the many counters available in Perfmon under the IIS Global object, as mentioned in Tip 8. Monitoring and fine-tuning your servers and network will help to ensure that your IIS-based Web site operates at peak efficiency.

Optimizing IIS
Microsoft * 206-882-8080
Web: http://www.microsoft.com