Max Number of Concurrent ASP Connections on IIS7

by techpilot007 29. March 2011 11:28

A little while back, November 2009, we were moving to another data center for our production servers and during the process we were upgrading from IIS6 on Windows Server 2003 to IIS7 on Widows Server 2008.  Our QA department had been testing the new servers for about a month and they kept reporting timeout.  Our planned switch to the new data center was only a couple of weeks away and we had no idea what the issue was.

I’m not sure how it came to be but we still were given the green light for this new environment.  Since this was a pretty big environment change and there was new code being released at the same time we pushed for this to be an in office release night (meaning all hands involved from development to product to infrastructure had to be in the office for the release).  The night of the release while we were waiting on the DNS update I was still searching for an answer to our timeout issue when another engineer said that he was noticing it only on the ASP portions of the site.

With this realization I was able to narrow my Google searches down and to learn more about how ASP is treated with IIS 7.  As it turns out, in IIS 7 ASP threads are limited by default as the expectation is that your site by now should be running VB or C#.  The limit is set to 12 concurrent threads per processor.  On our site this was extremely limiting.  So I continued to search for a way to modify this limitation and here is what I had to change.

In the registry I had to add this key.



In the ASPNet.config (C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet.config) I had to add a system.web section.

   <applicationPool maxConcurrentRequestsPerCPU="100" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>

The aspnet.config looked like this after I added the system.web section:

<?xml version="1.0" encoding="UTF-8" ?>
        <legacyUnhandledExceptionPolicy enabled="false" />
        <legacyImpersonationPolicy enabled="true"/>
        <alwaysFlowImpersonationPolicy enabled="false"/>
        <SymbolReadingPolicy enabled="1" />
        <applicationPool maxConcurrentRequestsPerCPU="100" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>

With these two changes our site was running smoothly and the switch over was pretty flawless.  If you’d like a more detailed explanation of the problem and resolution you can checkout these links below as these are the ones that helped me come to this fix.

Comments are closed


Welcome to the blog of an Configuration Manager. This blog is meant to share my thoughts, ideas, and the story of my ever expanding journey to acquire knowledge. It may, at times, include rants about or an expression of excitement over something in the computer realm. The majority of my work is with Windows servers. However, it has started to also include Linux machines. Lately I’ve become the Nagios “expert” within our company as I work towards creating culture of being proactive vs. reactive in regards to Application/Configuration Management.


(The information in this blog is provided “AS IS” with no warranties, and confers no rights implied or otherwise. The views, opinions, and ideas, expressed here are my own, and may not necessarily represent the views and opinions of my employer, past, current, or future.)



<<  December 2017  >>

View posts in large calendar