J
Jack Fox
While stress-testing our ASP.NET app, we discovered a flaw in our test
set-up, which also reveals a flaw in our ASP.NET configuration that we do
not know how to address.
We simulated too many clients, making requests faster than the bandwidth on
that part of the network could consume the responses. It seems that the
inability of the requestors to receive their responses causes IIS, and/or
aspnet_wp.exe, to eventually max-out its threads and come to its knees.
We changed our unrealistic virtual client distribution and distributed our
load generation to other parts of the network. Our app then did fine.
But.it seems that configuring more response load on the network than the
bandwidth can handle is a type of denial of service attack against
IIS/ASP.NET. How can we configure IIS and/or ASP.NET to prevent this?
set-up, which also reveals a flaw in our ASP.NET configuration that we do
not know how to address.
We simulated too many clients, making requests faster than the bandwidth on
that part of the network could consume the responses. It seems that the
inability of the requestors to receive their responses causes IIS, and/or
aspnet_wp.exe, to eventually max-out its threads and come to its knees.
We changed our unrealistic virtual client distribution and distributed our
load generation to other parts of the network. Our app then did fine.
But.it seems that configuring more response load on the network than the
bandwidth can handle is a type of denial of service attack against
IIS/ASP.NET. How can we configure IIS and/or ASP.NET to prevent this?