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


The information in this article applies to:

  • Microsoft Internet Information Services version 6.0
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, Standard Edition
  • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Server 2003, Datacenter Edition
  • Microsoft Windows Server 2003, 64-Bit Enterprise Edition
  • Microsoft Windows Server 2003, 64-Bit Datacenter Edition
Important This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SUMMARY

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 takes. You experience this problem with applications that use the synchronous ISAPI WriteClient API to send responses. You also experience this problem with applications that make more than one asynchronous ISAPI WriteClient call to send responses. This article lists the common symptoms that you may see when you experience this problem. This article also lists two methods that you can use to work around this problem.

SYMPTOMS

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

CAUSE

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

WORKAROUND

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

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: Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
  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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

To do this, follow these steps:Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
  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.

STATUS

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

MORE INFORMATION

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.

REFERENCES

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:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/iis/ref_vbom_resopb.asp

For more information about the WriteClient API, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesdkr/html/wcesdkrWriteClient.asp

For more information about Debugging Tools for Windows, visit the following Microsoft Web site:

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

555093 Very slow data transfers using RDS under Windows Server 2003, all versions

Modification Type:MajorLast Reviewed:10/30/2004
Keywords:kbtshoot kbRegistry kbnetwork kbISAPIExt kbenable kbBug kbAPI kbPerformance KB840875 kbAudDeveloper
©2004 Microsoft Corporation. All rights reserved.