Unreasonably slow performance posting files to IIS

I have a Web Service with a method that handles file uploads.
The file is sent as a DIME attachment to the SOAP request.
The post is successful, the file is received and the correct response is
sent back to the client.

The problem is that this is UNBELIEVEABLY slow!

My last tests were with a 4MB file.
The tests took between 30 and 40 seconds total.
The web service code finished its work in 750-790 milliseconds.
When monitoring the network interface the full 4MB of data were received in
1-2 seconds. The same is true when monitoring bytes received on the web
service application.

This would led me to the conclusion that a 4 MB post should take no more
than 4 seconds to handle.

Between the 1-2 seconds for the data to be received and the 790 millisecond
code execution there is NO data received by the webservice and there is NO
CPU use exept for what is normal when idle.

My question is: why? And what can be done to deal with this?

I have heard that this is an issue with newer versions of IIS caused by a
built in delay when receiving large amounts of data in a single request, and
that this is a non-configurable feature to limit the effects of attackers
posting large amounts of data to "block" the server. Is there any truth to
this?

Thanks in advance for any help/hints/tips anyone has.

Best regards
Sven Thorsen

David
Thu May 26 10:21:18 CDT 2005

Are you sure that you're not seeing a faulty extra socket Read in your web
service code that timed out after 30-40 seconds? What response is sent back
to the client (is it just echo'ing back what was read in?)

Can you also clarify the details (such as a URL) of what you are hearing
concerning: "a built in delay when receiving large amounts of data in a
single request, and that this is a non-configurable feature to limit the
effects of attackers posting large amounts of data to "block" the server"?

The closest thing I can think of is that HTTP.SYS does have a "minimum bytes
per second transferred" check that tries to defeat attackers that dribble a
4GB upload at 1 byte every second -- You agree that if the server accepted
lots of such requests that it'd soak up server-side resources, barely drain
any network bandwidth, yet completely block the server from handling
legitimate requests? But, this limit is fully configurable and shouldn't
come into play in your case since you said the POST'd data came within 2
seconds.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Sven Thorsen" <Sven Thorsen@discussions.microsoft.com> wrote in message
news:D45DC0E4-AE8A-439B-ACBB-8A2E7BCE1876@microsoft.com...

I have a Web Service with a method that handles file uploads.
The file is sent as a DIME attachment to the SOAP request.
The post is successful, the file is received and the correct response is
sent back to the client.

The problem is that this is UNBELIEVEABLY slow!

My last tests were with a 4MB file.
The tests took between 30 and 40 seconds total.
The web service code finished its work in 750-790 milliseconds.
When monitoring the network interface the full 4MB of data were received in
1-2 seconds. The same is true when monitoring bytes received on the web
service application.

This would led me to the conclusion that a 4 MB post should take no more
than 4 seconds to handle.

Between the 1-2 seconds for the data to be received and the 790 millisecond
code execution there is NO data received by the webservice and there is NO
CPU use exept for what is normal when idle.

My question is: why? And what can be done to deal with this?

I have heard that this is an issue with newer versions of IIS caused by a
built in delay when receiving large amounts of data in a single request, and
that this is a non-configurable feature to limit the effects of attackers
posting large amounts of data to "block" the server. Is there any truth to
this?

Thanks in advance for any help/hints/tips anyone has.

Best regards
Sven Thorsen

Sven
Fri May 27 07:26:03 CDT 2005


The response is correct, that is there are no errors. The response is
regular SOAP, customized serializable objects containing ID's and other
returned info. There is actually nothing wrong with anything except for the
horrible response times.

The QA department reported response times on their servers as follows:
24.5 KB - 1-2s
234 KB - 15s
2 920 KB - 118s

I have'nt seen THAT bad performance on my development computer, but that
might be because I did a bit of tuning of my internal buffer sizes. Still
30-40 seconds for handling a 4 MB file (as I'm experiencing on my machine) is
unreasonable. At least that's what I think...

I'm using the "Request Bytes In Total" counter on the "ASP.NET Applications"
object for my web service application instance. This reports receiving 4 MB
in 1-2 seconds, then there is a 30-40 seconds "pause" in activity before the
web service code is executed, and the code as I said executes in around 780
ms with a 4MB attachment. The delay time varies with the size of the
attachment.

The "built in delay" rumor is from a guy a guy in the operations department
called who aledgedly is good at IIS stuff. No link to give you, and I haven't
found anyting on the net describing anything similar. I don't really believe
it to be true (it does'nt seem plausible, at least not as a non-configurable
feature) but I thought I might just a