Lol, that's because they're trying to run it under IIS not Apache and are probably not using the ISAPI and an opcode cache. (running php as a plain cgi on IIS with the inability to cache the compiled scripts is a recipe for disaster.)
PHP5 has been very solid under IIS running as an ISAPI module using the eAccelerator opcode cache. However the XC hosted sites never see the load they are talking about, but I'm confident it would hold up under heavy load. Better yet once I move it to php5.3 running as a fastgci with the XCache opcode cache I expect even better performance.
Upshot: you can get excellent performance from php on windows if you use Apache, run it as a fastcgi and use an opcode cache. I'm reasonably confident that such a setup (like dynaverse.net) would hold up under heavy load... say a slashdotting. I expect our upload would be saturated long before the server would choke. If we had unlimited bandwidth, I would even venture to say that WAMP performance would be superior to LAMP. In my work I have found that MySQL performs better on windows than it does on *nux (have used mysql on Slackware, Redhat and QNX) In huge database tasks I find MySQL performance better on windows. (now dont start with the use a real db thing... though postgre is tempting at this point but I have no first hand platform performance observations to base making the change)
The trick is that IIS uses it's own opcode cache for PHP and other ISAPI's but eAccelerator has always performed better. I wonder if the changes in php5.3 that upset all the other opcode cachers is related to this development...
I have not setup php as a fastcgi under IIS yet but expect to have to do the job soon. I have run it under Abyss as a fastcgi and performance was actually better than apache/mod_fcgid, but I'm not sure how it would handle load.
Thanks for passing that along though, I was not aware MS's involvment to improve PHP under IIS. That is a good thing.
The other trick to this is that it is a fallacy that much php development is done on windows and run on Linux. My experience has been the exact opposite. PHP applications in general are developed for the *nix platform. I have spent much time replacing system calls in php that do not exist in windows (fnmatch, link and symlink are good examples).
That's why this news is big (one of the best changes in php 5.3):
http://www.php.net/manual/en/migration53.windows.php... which I expect is the story behind the story here.
I have seen php lock up on IIS, but more otften than not it relates to applications assuming linux system calls will be available and use the horrific @ operator (it should be banned - silent failure in any code is never an option) and you will often see the @ operator used used on php functions that were previously only available on Linux. I suspect also that IIS's own ISAPI cache suffers the same problems that other early opcode cachers suffered.
P.S. the Apache Winnt MPM has been stable for quite some time, all those dire warnings about running Apache 2 and php as a php module and its relation to thread safety are far outdated, but for some reason people still heed them.
P.P.S. mod_fcgid is the way to go, not mod_fastcgi.
P.P.P.S.
I maintain that php, run on windows as I've described, will blow perl on linux (apache/mod_perl) out of the water any day. Yes, you see the use of opcode caches in php applications but rarely (never?) do you see the scheduled (cron) generation of static html pages which is the most common perl load solution employed. Does not even compare in my books. While perl has it's uses (for things that are suited to be run on a schedule as opposed to dynamically). At least that is my take on this common and inappropriate comparison.
P.P.P.P.S. Damn... you got me going on a good rant there. I love it, I expect that you knew this would push my buttons.
P.P.P.P.P.S. (sorry) but I thought I'd add that not only have php applications traditionally been developed on and for linux, but in addition many php applications rely on Apache functionality and APIs.
So how do you make php suck less on windows? Use Apache - with the changes in php linked above, php will be more nearly platform independent (heavy apache reliance remains in the bulk of php applications).
That said, I have not used the latest IIS, which I understand is an improvement. I found the previous version an improvement over its predecessor, and IIS offers the advantage of easy administration and configuration (though with queer logging) so I'll really have to reserve judgement until I actually get php5.3 setup as a fastcgi on a later generation IIS install (6/7).
P.P.P.P.P.P.S (lol) Just ask MrCue, he'll
back me up.
Similar setup, much higher load...
Topic: How Microsoft Made PHP Suck Less on Windows (Read 1244 times)