IIS 7 and Above
Scalability problem using web requests initiating asynch web service...
Re: Scalability problem using web requests initiating asynch web serv...
Jan 14, 2013 04:11 AM|Toby999|LINK
Yes, thanks. I saw that last week. I tried to post a follow up comment on his blog, but it seems he turned it off now for further comments. Quite understandable if Thomas is not working with the se things anymore. I have some follow up questions at the bottom
of this comment though.
Though Thomas answers I think answered most of my questions. However, we were also able to establish last week that
setting ServicePointManager.DefaultConnectionLimit to int maxValue really does not make a difference since this already is the new default value in .NET 4.5. So essentially, it is not our
problem. We will most likely open a Microsoft support case on this issue later on this week. But as an input to this, I will write a summary of the problem + possible solutions as found o the Internet. I might as well post
it here before I mark anything as an answer. I'll follow up with another dedicated post for this.
Follow up information/questions on previous questsions/answers:
I found the performance counter for the HTTP.sys: HTTP Service Request Queues.CurrentQueueSize.
2 further questions regarding number of queues in the request pipeline:
So it seems that 3 queues have been identified so far then (1) HTTP.sys queue, (2) "native" queue, and the (3) .NET Thread Pool. I've looked a bit at the decompiled source code of WebClient that we are using (we changed from HttpClient
since this was too slow), but it is a bit too much source code to dig into. I am guessing though that at the .NET Framework level (above the CLR ThreadPool queue), there are no other queues that can cause the problem.
f) Is this a wrong assumption that between the .NET Threadpool and the WebClient asyc usage there are no queues? (this may be the wrong forum for that question, I know)
Information: Likewise, at a lower level, I guess there may be other queues in Kernal mode. Eg. network adaptor buffer. However, since this is Kernal execution level, it should
be more likely that the user mode level queues would be become the bottlenecks, not the native level queues. However, on the performance counter category [Network Interface] there is a counter called "Packets Received Discarded" that may rise if there if the
network card (driver) buffer is full (according to the description of the performance counter).
2 (f). Information:
For ayone interested: we found the performance couters for the outgoing connections in the [.NET CLR Networking 126.96.36.199] category. Several useful HttpWebRequests counters there.
2(e) Thread Pool thread counter question
So I don't understand why the "Process(w3wp)\Thread Count" and the ".NET CLR LocksAndThreads" only helps "a bit" as Thomas states. Why are these not accurate enough?