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.
What's wrong with apache?
One thing I've been keeping an eye on is WPHP. It's only alpha-quality at the moment, but it's basically a WSGI application (WSGI is the standard Python web application interface) with a FastCGI backend that runs PHP. With something like this, you can mix and match PHP and Python — for example, you could write an authentication handler in Python and link it to a legacy PHP application.
Bogtha Bogtha Bogtha
"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.
The game.
so you're paying out the nose, ears, ass for Windows and MS IIS and you care about free fastCGI?
And IMO, it may be free as in beer but it's poisoned beer by virtue of where it plays.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
If it tastes bad, there are always other beers. Unfortunatly, I can't brew my own beer. Nobody I know is good enough at it either. Ans I won't want to taste a beer brewwed by a thousand hands, thank you very much.
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
Since when did Zend "create" PHP?
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.
ah php, the unholy merger of c/c++, perl and java.
...and that is all I have to say about that.
http://jessta.id.au
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.
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.
Over on Linux, my perception is that FastCGI enjoyed a brief reawakening as it was (for a while) _the_ way to deploy Ruby on Rails apps with Apache. But now that seems to have changed to over to using Apache + mod_proxy_balancer + Mongrel.
One nice thing about mod_proxy_balancer is that it's easy to distribute the Mongrels across a couple of machines... and Apache will take them out of the loop if the machine goes down or they become unresponsive or whatever. Works for us, anyhow....
The Army reading list
Zend gives aid and comfort to the enemy.
Methinks it's all over but the funeral for FOSS.
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
Windows doesn't even support forking. You can start new processes, but forking the existing process is impossible. Even things like Cygwin only emulate it with threads.
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
"architected" is not a word, since "architect" is not a verb
A. You're wrong. English is a living language. Any word that people understand as a verb is a verb. You understood what was written, therefore you are lying.
B. Your conclusion ("architected" is not a word) does not automatically follow from your premise (since "architect" is not a verb). Your logic is not logical.
C. Any grammer nazi who does not capitalize the first word in a sentence is a hypocrite.
D. Any grammar nazi who does not end sentences with a period is a hypocrite.
E. Any grammar nazi who complains that the "nazi" in "grammar nazi" should be capitalized does not understand how words can be used in a generic sense and thus no longer be proper names.
F. Grammar nazis suck.
Infuriate left and right
Sorry, but that's bollocks.
Cygwin fork() does create a new process. It calls CreateProcess() and then copies the current process into the new one. See the relevant Cygwin API FAQ for a full explanation.
Why doesn't the gene pool have a life guard?
Apache does run on Windows. This seems to be widely overlooked. Everyone's primary reason for running IIS is "We have Windows". Seeing as they are both free, there must be some other reason for not using Apache. My guess would be lacking familiarity of and the learning curve to configure Apache.
Probably higher, considering the layers of security checks and "reducing the threat surface" whatnot which MSFT applied to IIS for Windows 2003 Server.
Quo usque tandem abutere, Nimbus, patientia nostra?
Congrats, Microsoft, you came in late for about a FULL DECADE and STILL people buy your crap. No matter how unethical is the fact that your "web" thing never did anything other than crash for no reason, spawn windows when anyone hit the webserver, and eat away all resources; people do bow unto you, take your crap and PAY FOR IT.
I can understand Microsoft very well. What ill never understand is its fanbois.
NO SIG
Win32 doesn't support forking, but the NT kernel does. For that matter, by far most of the expense of starting a Win32 process on Windows is due to Win32 subsystem overhead, including compatibility database lookups, not the kernel. SFU processes (that belong to the POSIX subsystem) and native processes (that belong to no subsystem) are MUCH cheaper, and incidentally support true kernel level copy-on-write fork.
Cygwin doesn't use the kernel's fork support because Cygwin is built upon on Win32. SFU can because it runs parallel to Win32.
Natural != (nontoxic || beneficial)
And if you have, say, 100 visitors at the same time? That's 3 seconds just to start the processes, much less actually run anything. It's multiplicative ;)
My blog. Good stuff (when I remember to update it). Read it.
A. You're wrong. English is a living language. Any word that people understand as a verb is a verb. You understood what was written, therefore you are lying. who knew that George Bush posted on Slashdot?
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).
I didn't mean to hurt your feelings or anything - There's a good reason why I qualified it as "probably" as opposed to "definitely".
/. modding up any crap someone tosses out on /. as it if were true. Bash MS, you get karma it seems, regardless of facts.
Didn't hurt my feelings; even probably implies that you have good reason to believe something. Good reason, not "well this is how I view things." I'm just sick of
If such follies as UAC in Vista is any indication (and that's just the tip of one very bloated iceberg), it's a pretty solid bet that MSFT simply tacked on more cycle-eating code to prevent break-ins.
And this has exactly what to do with Win2003 server? I can see you haven't actually used the product, so perhaps you should not comment on it with speculation. The OP posted some benchmarks at least. I at least work with Server 2003 everyday. Did you even check out the Server 2008 beta to see if this "safe bet" is as safe as you think?
In either case, don't complain to me - complain to Microsoft's marketing department, who went well out of their way to push that perception back when Windows Server 2003 launched (well, it came in second - right after the bazillion demonstrations showing how easy they made it to migrate for all the holdouts still using Windows NT 4.0).
Don't blame you for throwing out some statement for which you really have no basis in fact? I requested fact, you came back with your bias perceptions. Ya, I think I can blame you for that.