[Looking for Charlie's main web site?]

Did you know there's a "request execution limit" on IIS? It's 3, 10, 25, or unlimited, depending...

Did you know there's a "request execution limit" on IIS? It's 3, 10, or unlimited, depending on the version of Windows (Vista, 7, 2008) and edition (such as Starter/Home/Basic/Pro/Server).

I'll detail the limits per version/edition below.

I'll also offer a (possibly surprising) workaround that can allow you to get even more requests through IIS, even for a single web site.

(Before I elaborate on that, note that there is a separate issue if you're finding that CF doesn't let you see more than 25 requests at once. That's instead due to a setting in CF/JRun, the maxworkerthreads setting. For more on that, see this blog entry.)

That said, this is a problem which could affect anyone regardless of the app server they may be running behind IIS. (And yes, I do realize that for some, the answer to this problem will be, "see, that's another reason to run Apache." We get that. Let's just focus on this problem for those who choose/have to remain on IIS.)

Background

I was doing some load testing noticed that I couldn't get beyond 3 requests running at a time. I suspected the problem may be IIS.

So at first I tried just making the same requests against CF's built-in web server (such as might be running at port 8500, which can be enabled/configured during CF installation or manually).

Sure enough, CF could execute more requests at once (up to the "simultaneous requests" setting) through the built-in web server.

So that told me the problem had to be in IIS. I did some digging and found the documentation that affirmed what I was seeing.

(Some may recall there used to be a limit of 10 for IIS on Windows XP, so it may surprise some to run into an even lower limit on later Windows versions.)

IIS 7 does have a "request execution limit", for all but Server editions of Windows

The first resource I found was with respect to the limits in Vista. This page says specifically: "With Starter and Home Basic editions of Windows Vista, the simultaneous request execution limit for IIS is three for Windows Vista Home Premium. ...For Windows Vista Business, Enterprise, and Ultimate edition...the simultaneous request execution limit is ten. ..With server editions of Window, IIS 7.0 has no request execution limit."

But I'm sure some reading this will be using Windows 2008. I found a page discussing its limits: for the Basic & Starter editions: 3 requests, for Premium: 3, for Pro: 10, and for Server: unlimited.

I happened to be running Windows 7 when I hit the limit, and while I've not found a document stating the limits specifically for Windows 7, I can again confirm the same limit of 3 on my copy of Windows 7 Home Premium, so I'm sure things are the same, to whatever degree the edition names parallel the other versions. (It's curious that the learn.iis.net page above does discuss both Vista and Windows 2008, but makes no mention of Windows 7.)

A workaround for this limit: multiple worker processes

With respect to this limit, here's a valuable bonus tip that I've not seen documented anywhere: the limit is really per application pool, or more technically per worker process. So you can certainly get more request simultaneously against your box by using multiple app pools.

But perhaps you want to have more requests against a single site, which obviously can be connected only to a single app pool. There's still good news: you can increase the number of worker processes per app pool in the "advanced settings" for a given app pool (right-click on the app pool), increasing "Maximum Worker Processes" from the default of 1. (Some will recognize that as being the same as what was known as "web gardens" for app pools in IIS 6.)

For those new to them, whether creating new app pools or more worker processes for an app pool, for each new worker process, you'll see a new w3wp.exe in task manager.

A caution, for those using ASP.NET, about setting more than one worker process per app pool

Finally, there's a caution to consider if you decide to increase the number of worker processes. At least back in IIS 6, I documented that if you're running an ASP.NET app using sessions that are "inproc" (or in memory), the default, there is a problem with using multiple worker processes (web gardens), in that the sessions are not replicated among the worker processes. That may not be an issue for the OP, so I'll say you can learn more at an entry I did a few years ago.

Did any of this help you? Let me know below.

Update: Windows 8 and IIS 8

What about Windows 8 and IIS 8? See this info. This is referring to the client version of Windows 8. The server version is called Server 2012, and like the server edition of 2008, there are no request limits (according to comments on that blog entry).

Comments
Loved reading this post its good to see the real facts on this, made me rethink my own thoughts on the matter
# Posted By arimidex side effects | 9/5/11 4:58 AM
Can multiple worker processes per application pool cause problems with coldfusion9(jrun connector)?
# Posted By Demar | 10/24/11 4:52 PM
None that I'm aware of, Demar.
# Posted By Charlie Arehart | 10/25/11 4:23 AM
I will post again when it is confirmed but using more than one worker process seems to corrupt the IIS-->Jrun communications when used with Fusion-Reactor. If anyone else out there has done any load testing using multiple worker processes with CF9 Enterprise I would love to hear about it.
# Posted By Demar | 10/25/11 12:54 PM
The problem seems to have nothing to do with FusionReactor, it's just that people who have FusionReactor have seen the memory running high via FusionReactor.

I work for FusionReactor and we've helped several customers now with this issue where the protocol (JRPP) between the JRun ISAPI connector and JRun is breaking down causing the web requests to use up huge amounts of memory. FusionReactor does not alter or monitor that protocol in anyway.

Some customers have simply re-installed the JRun connector and the issue hasn't returned. We think that it may be related to mismatched versions of the JRun connector and CF but we cannot confirm that for every case yet. We are aiming to find the issue and report it to Adobe once we understand it.

If we find out more we'll let you know.
# Posted By Darren | 10/26/11 4:59 AM
Darren is correct. After creating new connectors I have not been able to reproduce the problem regardless of the number of application pool processes.
# Posted By demar | 10/27/11 5:40 PM
Very good to hear. Thanks, both of you for sharing your observations.
# Posted By Charlie Arehart | 10/28/11 3:56 AM
I read that increasing worker processes per application pool (web garden) does not affect the peformance and it's recommended to be 1 (default setting).
# Posted By ganaysa | 9/2/14 7:10 AM
@ganaysa, let me try to restate things: I too could make a case against using more than one worker process per app pool, agreeing that it doesn't "affect performance" for the better (in general, and especially with respect to CF), though we don't want to leave the impression that no one would ever benefit.

But to be clear, I was very specific in my reasoning for suggesting its use here: I was saying it's a way to get around the built-in limitation that IIS has--in some editions of Windows---to the number of requests that can be run concurrently.

So I would stand by my recommendation that even despite your assertion (which I would otherwise agree with) that in this specific case it COULD well "affect performance" positively.

Hope that's helpful.
# Posted By charlie arehart | 9/2/14 9:06 AM
Copyright ©2017 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting