Slashdot Mirror
Microsoft Releases IIS FastCGI Module
Marcy writes "Microsoft has just announced the final release of the IIS FastCGI module for IIS 5.1 (XP), 6 (2003), and 7 (2008). This FastCGI module was built with collaboration from Zend, the creators of PHP, and is intended to solve the CGI on Windows problem." It's free as in beer.
"Forking" (launching) a process is much more expensive on Windows than it is on Linux. Windows NT is architected after VMS (in part because of Dave Cutler). Processes are expensive on windows.
I was in a small shop where we already had IIS to run things like Outlook Web Access. IIS also made it easy to have integrated AD authentication and access controls, so we had single sign on.
Rather than running another box or supporting a VM image to run apache, it's easier just to make do with IIS. The point of this article is that MS is making IIS play better for people from the PHP/fcgi side of things.
We did however run the outside web server on apache on an ancient almost broken P166 and it ran well.
Its kind of a fallacy that 'forking' processes on Windows is significantly more expensive than forking them on Linux. I think it is somewhat more expensive, but that doesn't alter the fact that forking processes on linux is still expensive in the first place.
So, we needed ways to make things go faster - mod_php for example, that ran php scripts inside an apache process, but you still had to fork the apache process for each web request because of many thread-safety issues in php modules. This was also a security problem because every php script ran as the apache user. So the next idea was to start an apache process for each client and re-use it until that client disconnected (and stayed disconnected). This is the fastCGI approach.
With windows, you had 2 ways of running PHP scipts: as a CGI application (slow due to new processes all the time), and as an ISAPI (think of this as the equivalent of mod_php) module. The ISAPI one worked but you had the thread-safety issues of PHP to contend with (just like on Apache 2 that doesn't spawn worker processes).
In summary: nothing much to see, someone's just released fastCGI for IIS now so you have the same configuration options for IIS as you have for Apache.
Businesses utilizing PHP know Zend as the place to go for PHP expertise and sound technology solutions. Andi Gutmans and Zeev Suraski, two of Zend's founders, are key contributors to PHP and creators of the open source Zend Engine. Because of their internationally recognized authority, the company and its founders continue to play leadership roles in the PHP and open source communities, and are accountable for a central role in the explosive growth of PHP.
Slighty different, I think you'll agree.
Happy PHP'ing
29 mpg. YMMV.
I think it is somewhat more expensive...
It's a lot more expensive. Some numbers MSR came up with while working on their research OS Singularity put process creation on Linux at ~700,000 cycles, just over 1 million on FreeBSD, and just under 5.4 million cycles on XP. Here's one source; slide 23.
I'm not arguing against your main point; I'm just pointing out that there is actually a huge difference between process creation time on the different systems.
Because some people live and work in the real world. Not everyone runs a webserver just to show off their Pokemon collection, some of us get paid money to do this sort of thing - and sometimes the people paying the money want to use Microsoft.
Oh arse
You're talking about a flaw in a apache's security model there, not PHPs. Apache runs as a single user. When it runs PHP as a module, then PHP runs as a single user. Same with Perl, or Ruby, or anything else that relies on a module interface as far as I know. If you use FastCGI (which this article is about, you may have noticed) then you can get it to suexec to a different user when it makes the CGI process, and you don't have the security problem you're whining about.
The bit about PHP admin scripts is application specific - nobody's forcing the authors to do it that way, and you can do the same with any other language. PHP has had it's flaws (register_globals and magic_quotes still give me the shivers), but if you're going to bitch about it, at least educate yourself first.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
It's trivial on the apache side, and relatively easy on the iis side.
Config the machine to have two IPs.
On apache, set a Listen directive in the config file, to have it listen on IP1:80.
For IIS, run this:
c:\>httpcfg set iplisten -i IP2
By default, both apache and IIS will bind to every IP on the box. These methods let you have each listening on port 80 on their respective IPs.
The only 'hard' part on the IIS side is knowing that httpcfg exists and controls this. If you've ever setup wildcard ssl certs in windows you've been here.
The reason this is controlled through this command prompt on windows is due to the architecture of IIS.
There is a very small kernel-mode component that handles listening on the port and handing off to IIS. This is what you're configuring with httpcfg.
I believe Vista (and therefore Win 2008 Server) doesnt have httpcfg and uses something else (dont know what off the top of my head).