Microsoft KB Archive/840875

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

Article ID: 840875

Article Last Modified on 12/3/2007

-

APPLIES TO


 * Microsoft Internet Information Services 6.0
 * Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
 * Microsoft Windows Server 2003, Standard Edition (32-bit x86)
 * Microsoft Windows Server 2003, Web Edition
 * Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
 * Microsoft Windows Server 2003, Enterprise x64 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. </li> 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 &quot;503 Service Unavailable&quot; 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.</li> The global maximum connections limit for HTTP. The global maximum connections limit for HTTP is 8000 connections on x86-based computers.</li></ul> </li> 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:

<pre class="fixed_text">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

</li></ul>

<div class="cause_section">

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

<div class="workaround_section">

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:

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. <ol> Click Start, click Run, type regedit in the Open box, and then click OK .</li> In Registry Editor, locate and then click the following registry subkey:

</li> On the Edit menu, point to New, and then click DWORD Value.</li> In the right pane of Registry Editor, type MaxCopyThreshold, and then press ENTER.</li> Double-click the MaxCopyThreshold registry entry. The Edit DWORD Value dialog box appears.</li> Type the appropriate value in the Value data box, and then click OK.</li> Quit Registry Editor.</li> Restart the computer.</li></ol>

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.

<div class="workaround_section">

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: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. <ol> Click Start, click Run, type regedit in the Open box, and then click OK .</li> In Registry Editor, locate and then click the following registry subkey:

</li> On the Edit menu, point to New, and then click DWORD Value.</li> <li>In the right pane of Registry Editor, type EnableCopySend, and then press ENTER.</li> <li>Double-click the EnableCopySendregistry entry. The Edit DWORD Value dialog box appears.</li> <li>Type 1 in the Value data box, and then click OK.</li> <li>Quit Registry Editor.</li> <li>Restart the computer.</li></ol>

<div class="status_section">

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the &quot;Applies To&quot; section.

<div class="moreinformation_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.

<div class="references_section">