BUG: IIS 6.0 is slower than IIS 5.0 when you use the WriteClient API to send data

You may notice that Microsoft Internet Information Services (IIS) 6.0 takes a longer time to send HTTP response data packets through the WriteClient API than IIS 5.0. This condition typically occurs with the following types of applications:

• Applications that use the synchronous ISAPI WriteClient API to send responses.
• Applications that make more than one asynchronous ISAPI WriteClient call to send responses.

The following lists common symptoms that you may notice when you experience this problem:

• When you use Performance Logs and Alerts to monitor the Requests/sec counter of the Web Service object, the performance of the server is slow when it is compared to the performance of a server that is running IIS 5.0 on similar hardware. You may notice that IIS 6.0 processes approximately half the requests per second as IIS 5.0 processes.
• Clients may experience one or more of the following symptoms:
  • Clients experience increased delays when the clients receive responses from the server.
  • Clients receive an error message that is similar to the following:
    503 Service Unavailable
  • The connection to the server is reset when the client sends a request.
• CPU usage is typically low. However, requests accumulate in Http.sys. When you use Performance Logs and Alerts to monitor the Current Connections counter of the Web Service object, you notice that requests to the server reach the maximum queue length for requests. By default, the maximum queue length is 4000 connections. After the requests exceed the maximum number of connections, the server returns "503 Service Unavailable" error messages to the clients. An indication that requests accumulate in Http.sys is that the value of the Current Connections counter is very similar to the lesser of one of the following two values:
  • The request queue length.
  • The global maximum connections limit for HTTP. The global maximum connections limit for HTTP is 8000 connections on x86-based computers.
• In applications that use synchronous ISAPI, most of the worker process threads in IIS are blocked. The threads are waiting for the send operation to be completed. You use a Microsoft Windows user-mode debugging tool, such as the WinDbg tool, the Ntsd tool, or the Cdb tool to verify this condition. When you attach the debugger tool to the worker process that serves the ISAPI requests, you notice that the majority of worker threads in the process are blocked in calls to the HttpApiSynchronousDeviceControl() component. Typically, the worker process that serves the ISAPI requests is the W3wp.exe process. The following is an example of a call stack that is generated when this problem occurs:

  ChildEBP RetAddr  
  017af62c 77f43741 SharedUserData!SystemCallStub+0x4
  017af630 67153781 ntdll!NtWaitForSingleObject+0xc
  017af658 67151c61 httpapi!HttpApiSynchronousDeviceControl+0x57
  017af67c 67152db0 httpapi!HttpApiDeviceControl+0x23
  017af6cc 5a3616b7 httpapi!HttpSendResponseEntityBody+0x64
  017af710 5a36170d w3dt!UL_NATIVE_REQUEST::SendEntity+0x7c
  017af730 5a3944cd w3dt!UlAtqSendEntityBody+0x1d
  017af75c 5a399987 w3core!SendEntityBodyAndLogDataHelper+0x7c
  017af798 5a399a3a w3core!W3_RESPONSE::SendEntity+0xf1
  017af7bc 5a39b38c w3core!W3_CONTEXT::SendEntity+0x8c
  017af7d8 5a32378d w3core!ISAPI_REQUEST::WriteClient+0xf7
  017afa3c 10016dfe w3isapi!WriteClient+0x27d
  77e42f38 458b18ec 

This problem occurs because of a difference in buffering mechanisms in Http.sys in IIS 6.0 and in IIS 5.0.

To work around this problem, use one of the following methods, depending on your situation.

Method 1: Add the MaxCopyThreshold registry entry

You may also experience this problem in applications that use the WriteClient API for asynchronous calls and that make two or more WriteClient calls per HTTP response. If you suspect that you are experiencing this problem, add the MaxCopyThreshold registry entry to the following registry key: To improve performance and memory usage, we recommend that you set the MaxCopyThreshold registry entry to the lowest possible value. We recommend that you test the following values, and then use the lowest value that corrects this problem:

• 8192
• 16384
• 32768
• 65536
• 131072

To add the MaxCopyThreshold registry entry, follow these steps: Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. In Registry Editor, locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
3. On the Edit menu, point to New, and then click DWORD Value.
4. In the right pane of Registry Editor, type MaxCopyThreshold, and then press ENTER.
5. Double-click the MaxCopyThreshold registry entry. The Edit DWORD Value dialog box appears.
6. Type the appropriate value in the Value data box, and then click OK.
7. Quit Registry Editor.
8. Restart the computer.

Method 2: Add the EnableCopySend registry entry

Use this method only for ISAPIs that perform synchronous send operations. You can also use this workaround if at least one synchronous ISAPI experiences a network delay. However, this method does not work in an environment where the majority of the clients use slow links, such as modems.

To apply this workaround, add the EnableCopySend registry entry to the following registry subkey, and then set the registry entry to 1: To do this, follow these steps:Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. In Registry Editor, locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
3. On the Edit menu, point to New, and then click DWORD Value.
4. In the right pane of Registry Editor, type EnableCopySend, and then press ENTER.
5. Double-click the EnableCopySendregistry entry. The Edit DWORD Value dialog box appears.
6. Type 1 in the Value data box, and then click OK.
7. Quit Registry Editor.
8. Restart the computer.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies To" section.

The following lists implications to consider when you use either the EnableCopySend registry entry or the MaxCopyThreshold registry entry:

• Both registry keys instruct the Http.sys driver to use more memory.
• The total number of connections that Http.sys can handle is reduced if you use either of these registry entries.
• CPU usage on the server increases because of the additional overhead that results from buffering data.

If response buffering is disabled in IIS 6.0, you also experience this problem with Active Server Pages (ASP). By default, response buffering is enabled in IIS 6.0, and you do not experience this problem. For additional information about response buffering, visit the following Microsoft Web site: For more information about the WriteClient API, visit the following Microsoft Developer Network (MSDN) Web site:For more information about Debugging Tools for Windows, visit the following Microsoft Web site: For additional information, click the following article number to view the article in the Microsoft Knowledge Base: