Random thoughts while unwinding down…


Lately, IIS7 has taken a disproportionate amount of my attention, so now that the milestone has been reached, I finally have a chance to unwind my mind. My thoughts are going to be a bit random for a while (at least to me it seems so). But, do not be surprised if I still ooze a bit of IIS7-related information here and there…


To WOW64 or not to WOW64…


While working on x64 and issues surrounding WOW64 support IIS7, it made me realize that regardless of the fact that WOW64 support is considered “App Compat” and support was added to IIS6 in Windows Server 2003 SP1 it is going to be there indefinitely because 32bit code will hang around for a long, long time. So, despite how “icky” and “bizarre” WOW64 looks, it has to work well on IIS7 and likely beyond. Yea, talk about legacy!


The amusing thing to me is that what the IIS product team considers “legacy” right now is probably what users will consider “state of the art” several years from now, when your IT procurement process actually allows Windows Server 2003 SP1 to be installed and supported. And how many web applications/components are YOU going to recompile to move onto an x64 system iat that time? How long are those components going to last? And how many native components will you be developing? Uh-huh…


Sigh… I suspect the current lull of questions about WOW64 is either because people are going pure 64bit all the way, or people simply have not adopted 64bit yet… and I think the latter is more realistic.


And that approach is perfectly fine… though you will certainly be missing out on a couple of performance gems as far as IIS6 is concerned:



  • x64 is a more scalable platform than x86 because you can handle more simultaneous connections than ever possible on x86 – the OS-limit on Non-Paged Pool no longer exists for HTTP.SYS.

  • Larger address space = more cache memory for HTTP.SYS to take advantage of.

More WOW64


Here are some more WOW64 on x64 thoughts to chew on:



  • For Windows binaries, 64bit binaries are in System32, and 32bit binaries are in Syswow64

  • For .Net Framework binaries, 64bit binaries are in Framework64, and 32bit binaries are in Framework.

  • Even more interesting is that the above directories that contain Windows system binaries has WOW64 FileSystem redirection applied for 32bit processes, but NOT the .Net Framework binaries. So, can you tell me WHICH aspnet_regiis.exe should be run for registration with IIS, and for what IIS w3wp.exe bitness?

  • And how should existing and future x86 applications figure out how to install on x64 in WOW64 mode AND deal with the fact that IIS can change its w3wp.exe to be either 32bit or 64bit. I can see the wheels spinning and the eyes glazing over already…

It is all crystal clear, right? Yeah… as clear as a foggy crystal ball…


Hmm, this sounds like a good future blog topic to me… deciding if WOW64 is the right choice (remember, it is supposed to be App Compat), and if so, the Ins/Outs of how to configure/work with it on IIS6 and beyond.


There are a couple of KB articles about WOW64 and IIS6, but “technical editing” and “publication” processes seem to botch up my message in one way or another. Well, no longer. I can now write and publish that information with the exact details and wording that I want, direct from me to you, and no middle man filters. 🙂 One thing I like about blogging…


Yeah, yeah… I will get back to technical articles eventually. A couple of you have been persistently pinging me about some interesting topics… to be disclosed shortly. I will probably get back to the usual “featured programming” after this weekend.


//David.

Comments (2)

  1. Ed Goward says:

    Thanks for the info – every little helps 🙂

    Is there anything useful to be said about thread count / stack size limitations on 32 versus 64 bit? Being able to have 1 thread per connected client is useful – obviously not optimal, but more feasable in a 64 bit address space, right? Performance always has to come second to quality/reliability – or so they say.

    I imagine talking to actual end users about x64/IA64 is a bit of a loss, but there are lots of software houses / consultancies around targetting IIS, and we need to know – some diagrams showing how different bits of IIS on x86-32 and x86-64 fit together would be nice. Maybe put IIS on IA64 in too – that’s presumably the kind of architecture we get when we drop the backward compatibility with Win16^h^h32?

  2. David.Wang says:

    Don’t worry, there is more to WOW64 and x64. I have that planned for another blog entry. 🙂

    You are also reminding me to write another blog entry just about your comment (I mean no offense to you personally – you are just illustrating a misconception that many people have). I will toss in the preview below.

    Basically, if you are talking about thread count/stack size "limitations" on performance, you must be talking about badly behaving user code… because good code will not be bumping into those "limitations".

    Also, you do not have 1 thread per connected client – even on x64 and you have 10,000 simultaneously connected clients, you do NOT want to have 10,000 threads. Remember, HTTP.SYS and IIS6 is asynchronous, so that load can easily be handled by something like 5-10 threads and a queue, assuming the user code is written correctly.

    That’s right. When you write your code to be properly asynchronous, the same 5-10 threads can handle 10 simultaneous connections or 10,000 simultaneous connections. Asynchronous IO operations do not tie up IIS worker threads, unlike synchronous operations.

    Unfortunately, synchronous operations is easiest for people to understand, and yes, if your user code is synchronous, you end up needing 1 thread per connection. This is the reason that synchronous code cannot scale and require bumping up thread-count or stack limits — at the cost of performance because more threads = more context switching = less performant work being done per unit time. Yes, you can see performance gains in synchronous code by bumping up thread count, but only up to an arbitrary point… that does not scale.

    //David

Skip to main content