ColdFusion Muse

IIS 7 Max Worker Processes and ColdFusion Updated

In my previous post on this topic I indicated that IIS 7 seemed to be a constraining factor. That post lead to conversations with a couple of CF gurus (Charlie Arehart and Russ Michaels) who clued me in to a number of additional settings. If you are truly interested take the time to read the previous post and (especially) the comments before you read this post. What bothered me was that the issue I discovered (a cap on requests) can be affected by both IIS settings or JRUN settings (or both).

My conclusion is that the behavior I was trying to affect is actually the bug that Charlie pointed out to me on Adobe's site (found here). Charlie rightly indicates that this issue is under-recognized (I certainly had not run into yet). The behavior of this bug can be affected (fixed or mitigated) by adjusting IIS as described in my previous post as well as by using the Adobe-provided instructions. This lead to a bit of Muse head-scratching. How do these various processes really work together? This post hopes to clear that up (or at least add to our compendium of knowledge).

First, the short answer is that Charlie is right that the maxworkerthreads setting in the jrun_iis7_wildcard.ini file will solve this problem. Starting with a default setting of 1 for "Maximum Worker Processes" in the IIS7 application pool settings and uncommenting the maxworkerthreads and setting it to 50 (maxworkerthreads=50) or any number at least as large as your simultaneous requests setting will remove the cap of 25 maxworkerthreads just exactly as Charlie insisted. And I should know better than to doubt our resident CF scholar :)

To answer the other question however the maxworkerthreads setting is clearly multiplied by the IIS7 maximum worker processes setting. So when you play with these settings keep in mind that setting the maxworkerthreads to say 50 in your jrun_iis7_wildcard.ini file and then setting the maximum worker processes to 2 in the IIS 7 application pool settings will result in ColdFusion potentially handling 100 requests concurrently (2 IIS worker processes times 50 max worker threads).

To prove this to myself I started with the following settings:

  • IIS 7 Max Worker Processes = 1
  • maxworkerthreads= 10 in jrun_iis7_wildcard.ini for my instance
  • Simultaneous Requests = 32 in CF Admin.
  • A single CF instance with a single site
Then I used my load test to put enough pressure on the server to max out the CF request queue (this was a baseline I knew from previous testing). I expected to be limited to 10 requests. Sure enough, as expected I capped out at 10 requests. Take note of how this works. This particular limit is bound to the IIS worker process. It's about the connector not the application engine. That means the requests queue in IIS - not in CF. In other words you will not see queued requests climbing in Fusion Reactor or the CF monitor. But if you use perfmon you can see them queing in IIS.

With my test running and observing my "active requests" steady at 10 with excess requests queuing in IIS and not in CF, I set the "max worker processes" to 2. My cap bounced up to 20. Requests were still queuing in IIS (and not in CF). I bounced to 3 and my cap held steady at 30. No CF queue yet (remember my simultaneous requests setting is 32). When I bounced max worker processes to 4 however my "active requests" made it to 32 but no further. Instead I now had a queue in ColdFusion of 8. With a max worker process of 5 I got a queue of 10 to 12 (that was the limit of my test tolerance).

Lessons Learned

Remember this default capping behavior is per connector not per instance. One of my servers running in multi-server mode has 24 or 25 sites on it - each of them connected to a specific instance with its own jrun_iis7_wildcard.ini file and its own application pool. So the total number of potential requests handled by that instance is a multiple of application pools x max worker processes x maxworkerthreads (or the default of 25 if that setting is commented out as it is by default).

To put it another way the overall number of connectors you are using against an instance will multiply the number of potential concurrent requests forwarded to ColdFusion. If you have a single instance with say 10 sites each with its own application pool and each connected to the same ColdFusion instance, you will end up with 10 worker process threads and therefore 10 times 25 (if using the default) maximum concurrent CF requests.

So shared servers with multiple sites might appear to not be affected by this bug. But if you think about it they are affected. With the default settings no app pool can get more than 25 requests active concurrently. That's a problem that could easily "hide" on a shared server (especially a busy one).

Is this useful in some way? It occurs to me that on a shared server you could create a sort of throttle behavior by adjusting these settings - limiting a specific site to only 10 concurrent requests sent to JRUN at a time. Let's say you have a particular site (a batch instance for example) with a tendency to gobble up too many threads, but you don't have enough resources on the server to give it its own instance. Instead you might limit the amount of work that the particular instance can do on behalf of that site by setting maxworkerthreads to some number (say 10) and max worker processes to 1.

Incidentally I do not object to having more than one "worker process" (w3wp.exe) in IIS as long as you don't go crazy. Indeed, in IIS7 each "site" is created with a new application pool (unless you reuse them) and each application pool spawns its own w3wp.exe process. These worker processes tend to have a small footprint overall and using 2 or 3 instead of 1 is a fairly modest configuration change that might actually improve your performance in some cases.

In any case it is interesting to see how these settings work together and I feel like exploring this process has added some additional information to our growing arsenal. Thanks to both Russ (a.k.a. "Snake") Michaels and the inestimable Charlie Arehart for poking at me on this and helping me figure out the relationships between these various settings and processes.

Related Blog Entries

Comments
Paul Kukiel's Gravatar I remember this exact issue from this blog post: http://blog.kukiel.net/2009/10/coldfusion-9-on-win... ( read comments )

It was actually only days after I made the comment did Adobe come out and make there official blog post.
# Posted By Paul Kukiel | 11/6/11 2:27 AM
Aaron Greenlee's Gravatar Thanks for helping to clear this up!
# Posted By Aaron Greenlee | 11/6/11 10:48 PM
Charlie Arehart's Gravatar Thanks for digging a little more, Mark, and really glad to have helped. Thanks for all the kind regards. ;-)
# Posted By Charlie Arehart | 11/11/11 11:21 PM
Michael Taich's Gravatar Thank you all for the very helpful information. I have a question, though: does anyone know why would my CF9 installation on Windows Server 2008 R2 (IIS7.5) not to have the "jrun_iis7_wildcard.ini" file, but "jrun_iis6_wildcard.ini" instead (at the proper location)?
# Posted By Michael Taich | 1/5/12 4:26 PM
Charlie Arehart's Gravatar Are you running 9.0 or 9.01? Either way, I'll take a guess: perhaps you are running IIS in IIS 6 compatibility mode.

Prior to CF 9.01, this was required to run CF with IIS 7 (whether CF 7, 8 or even 9.0). Only 9.01 has lifted that requirement lifted.

Even if you may be on 9.01, it could be that someone didn't notice this and left IIS 7 running in IIS 6 Compat mode (And the installer or web server conf tool was run while it was.)

(As to how to check whether IIS 6 Compat is enabled, see the CF install docs or any of several blog entries that walked through how to enable it before 9.01 lifted the requirement. One showing it for Windows 2008 specifically is http://moodyconsumer.blogspot.com/2009/08/coldfusi...

Let us know if that helps.
# Posted By Charlie Arehart | 1/5/12 4:59 PM
Michael Taich's Gravatar Charlie, I have 9.0 and, yes, I do have IIS6 compatibility roles installed. Do you think, that in my case the "jrun_iis6_wildcard.ini" is being used by JRUN correctly (meaning -- instead of "jrun_iis7_wildcard.ini")?
# Posted By Michael Taich | 1/5/12 5:28 PM
Charlie Arehart's Gravatar Well, I'm saying that (I suspect) you therefore need not worry about anything. Sorry I don't have a more precise answer, but from what we've discussed here, I think you could just let it be (if it was just a mild curiosity). But perhaps someone else will have a more definitive answer for you.
# Posted By Charlie Arehart | 1/5/12 5:39 PM
Nik Stephens's Gravatar Extremely helpful post, bizarre that it more folks haven't run into it? One thing that has perplexed me, and this brought it up again. Can anyone explain why, on a clean install of Win2008 with CF9.01, and IIS 6 compatibility having never been turned on, I have jrun_iis6_wildcard instead of jrun_iis7_wildcard?
# Posted By Nik Stephens | 4/12/12 5:06 PM
Mark Kruger's Gravatar @Nik,

I think it's a simple fact of the connector path or name not being updated to include a "7". I don't know of any other reason - but maybe Charlie does.

-mark
# Posted By Mark Kruger | 4/12/12 5:12 PM
Mark Murdock's Gravatar We have the same situation: A jrun_iis6_wildcard.ini file but no jrun_iis7_wildcard.ini file, and we're definitely using IIS7. Should we just modify the iis6 file?
# Posted By Mark Murdock | 5/17/12 2:27 PM
Michael Taich's Gravatar Mark,

I cannot guarantee that the file is being actually used by CF/IIS7, but I did modify it in my case.
# Posted By Michael Taich | 5/17/12 3:06 PM
Ajas's Gravatar Hmm, I saw a similar issue but with slight difference that Nik Stephens pointed out. In this case "On a clean install of Win2008 with CF9.01, and IIS 6 compatibility was turned on initially and then turned off, and CF 9.0.1 was reinstalled and connector was run for all sites. I have jrun_iis6_wildcard instead of jrun_iis7_wildcard". I dont know why its that way. Any updates or news on this?
# Posted By Ajas | 11/5/13 12:47 AM



Blog provided and hosted by CF Webtools. Blog Sofware by Ray Camden.