We are running an investigation on a scalability issue using outgoing asynchronous web requests on IIS 7.5. This is long story and it is documented here with
a number of open questions for anyone to read (and give feedback if you want). However, as a possible fix to this problem we need to try to change some
ThreadPool configuration values on the processModel and httpRuntime configurations in machine.Config and web.config. (instead of running with processmodel autoConfig=true in machine.config.)
So by doing these changes, I came up with some questions that I think are suiteful for this forum:
A. Confirming that the applied changes have been adopted by the ThreadPool
Once the processModel config changes in machine.Config has been applied, we would like the web application to give some feedback of that the changes has been applied. We have found three possible ways to verify this:
1) ThreadPool properties GetMaxThreads and
GetMinThreads should be able to render the correlating config values
processModel: maxWorkerThreads, maxIoThreads, minWorkerThreads, minIoThreads.
2) The ProcessModelSection .NET class should be able to give many of these values back including the
MinWorkerThreads which is not available via the ThreadPool class.
However, when querying these values on our production server (Win 2008 R2 / .NET 4.5), the values do not appear correctly. The AutoConfig is set to false although it is set to true in Machine.Config. And when changing this the value to false instead
in machine.Config as well as setting higher value on MinWorkerThreads to 50, the MinWorkerThreads property of the class still outputs 1. Question 1: What’s up with this?
3) Another way, as suggested in
this forum post (at the bottom), is to reflect on typeof(HttpRunTime). have a number of questions here:
Before the change the Max Worker Thread had a value 32767 (should be max Int16 size). Following the suggestion in the this Microsoft
tech article 821268 (“Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications”) we set the maxWorkerThreads on processModel to its max value 100 (according
to MSDN processModel reference). Applying the change on the web page does reveal the new value 1600 which is correct since there are 16 logical cores.
Question 2: What’s up with the value 100 being the max value when clearly 32767 was possible?
There is a fields value of class httpRunTime called _queueLimit with a value stating 5000 on our production server.
Question 3: What queue is this and is it true? Question 4: How is it possible to change this value in a config file?
There are two fields called _localQueue as well as _externQueue with values 0 supposedly showing the number of queued items currently. Question 5: What queues are those? (see a list of queue I’ve made
here)
1) When reading about processModel autoConfig=true/false
here (MSDN), it says that when this value is true, the five configuration attributes listed here (maxWorkerThreads, maxIoThreads, minFreeThreads, minLocalRequestFreeThreads, and maxConnection)
“are set according to the KB article at
http://support.microsoft.com/?id=821268”. Question 6: Should this be interpreted that the values are set by ASP.NET according to the Resolution, Recommendation section in this article if autoConfig=true?
2) The recommendation on
http://support.microsoft.com/?id=821268 for minFreeThreads is 88*N where N is the number for the logical number of processors. According to the note on this web site: “When you use this configuration, you can execute a maximum of 12 ASP.NET requests
per CPU at the same time because 100-88=12. Therefore, at least 88*Nworker threads and 88*Ncompletion port threads are available for other uses (such as for the Web service callbacks).” Question 7: Is this 12 requests per core as it says or 12 threads per core? In an asynchronous case when the thread is returning to the thread pool after making the web service requests, this number quite is high. However the number is low if is actually
requests which should include the latency time for the web service callback method to be called and the request finally finished.
3) Question 8: If .NET 4.5 is being used and the .NET new default value of ServicePointManager.DefaultConnectionLimit as max value of int is not changed, can the default value of maxConnection really be a bottleneck then
as this article is saying?
Your question falls into the paid support category which requires a more in-depth level of support. Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone
Yes. We actually opened up a paid support with Microsoft recently case to solve the main problem as described
here. We managed to get good feedback from Microsoft support and some improvements in this problem. I also asked if I could get answers on the questions above, but I was not able to get these answers. I guess it may have to be a dedicated support request
for these questions so that the correct people at Microsoft may contribute with the answers. But right now, I think these answers are not important enough in order to solve the main problem so it is gonna have to wait I'm afraid. If I stumble upon the answers
in the future, I'll try to remember to update these questions with answers so that others can be helped.
Toby999
Member
1 Points
6 Posts
Configuration changes to ThreadPool via processModel and httpRuntime?
Jan 17, 2013 05:37 PM|LINK
We are running an investigation on a scalability issue using outgoing asynchronous web requests on IIS 7.5. This is long story and it is documented here with a number of open questions for anyone to read (and give feedback if you want). However, as a possible fix to this problem we need to try to change some ThreadPool configuration values on the processModel and httpRuntime configurations in machine.Config and web.config. (instead of running with processmodel autoConfig=true in machine.config.)
So by doing these changes, I came up with some questions that I think are suiteful for this forum:
A. Confirming that the applied changes have been adopted by the ThreadPool
Once the processModel config changes in machine.Config has been applied, we would like the web application to give some feedback of that the changes has been applied. We have found three possible ways to verify this:
1) ThreadPool properties GetMaxThreads and GetMinThreads should be able to render the correlating config values processModel: maxWorkerThreads, maxIoThreads, minWorkerThreads, minIoThreads.
2) The ProcessModelSection .NET class should be able to give many of these values back including the MinWorkerThreads which is not available via the ThreadPool class. However, when querying these values on our production server (Win 2008 R2 / .NET 4.5), the values do not appear correctly. The AutoConfig is set to false although it is set to true in Machine.Config. And when changing this the value to false instead in machine.Config as well as setting higher value on MinWorkerThreads to 50, the MinWorkerThreads property of the class still outputs 1.
Question 1: What’s up with this?
3) Another way, as suggested in this forum post (at the bottom), is to reflect on typeof(HttpRunTime). have a number of questions here:
Before the change the Max Worker Thread had a value 32767 (should be max Int16 size). Following the suggestion in the this Microsoft tech article 821268 (“Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications”) we set the maxWorkerThreads on processModel to its max value 100 (according to MSDN processModel reference). Applying the change on the web page does reveal the new value 1600 which is correct since there are 16 logical cores.
Question 2: What’s up with the value 100 being the max value when clearly 32767 was possible?
There is a fields value of class httpRunTime called _queueLimit with a value stating 5000 on our production server.
Question 3: What queue is this and is it true?
Question 4: How is it possible to change this value in a config file?
There are two fields called _localQueue as well as _externQueue with values 0 supposedly showing the number of queued items currently.
Question 5: What queues are those? (see a list of queue I’ve made here)
B. Following the recommendation in tech article 821268
1) When reading about processModel autoConfig=true/false here (MSDN), it says that when this value is true, the five configuration attributes listed here (maxWorkerThreads, maxIoThreads, minFreeThreads, minLocalRequestFreeThreads, and maxConnection) “are set according to the KB article at http://support.microsoft.com/?id=821268”.
Question 6: Should this be interpreted that the values are set by ASP.NET according to the Resolution, Recommendation section in this article if autoConfig=true?
2) The recommendation on http://support.microsoft.com/?id=821268 for minFreeThreads is 88*N where N is the number for the logical number of processors. According to the note on this web site: “When you use this configuration, you can execute a maximum of 12 ASP.NET requests per CPU at the same time because 100-88=12. Therefore, at least 88*N worker threads and 88*N completion port threads are available for other uses (such as for the Web service callbacks).”
Question 7: Is this 12 requests per core as it says or 12 threads per core? In an asynchronous case when the thread is returning to the thread pool after making the web service requests, this number quite is high. However the number is low if is actually requests which should include the latency time for the web service callback method to be called and the request finally finished.
3) Question 8: If .NET 4.5 is being used and the .NET new default value of ServicePointManager.DefaultConnectionLimit as max value of int is not changed, can the default value of maxConnection really be a bottleneck then as this article is saying?
Parashuram
Member
98 Points
39 Posts
Re: Configuration changes to ThreadPool via processModel and httpRuntime?
Feb 15, 2013 12:14 AM|LINK
Your question falls into the paid support category which requires a more in-depth level of support. Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone
Toby999
Member
1 Points
6 Posts
Re: Configuration changes to ThreadPool via processModel and httpRuntime?
Mar 07, 2013 02:58 PM|LINK
Yes. We actually opened up a paid support with Microsoft recently case to solve the main problem as described here. We managed to get good feedback from Microsoft support and some improvements in this problem. I also asked if I could get answers on the questions above, but I was not able to get these answers. I guess it may have to be a dedicated support request for these questions so that the correct people at Microsoft may contribute with the answers. But right now, I think these answers are not important enough in order to solve the main problem so it is gonna have to wait I'm afraid. If I stumble upon the answers in the future, I'll try to remember to update these questions with answers so that others can be helped.