Posted
by
Zonkon Tuesday March 04, 2008 @12:22PM
from the dogs-and-cats-living-together dept.

Stony Stevenson writes "It used to be that popular PHP applications would run more poorly on Windows Server than on a Linux or Unix servers, for which PHP had been optimized. Specialist in the PHP language Zend Technologies now says that's no longer the case. The Zend Core commercially supported form of PHP has been certified by Microsoft as ready to run 'with performance and stability' on Windows Server 2008, said Andi Gutmans, co-founder and CTO of Zend. Previously, PHP 'didn't run as well as it should on Windows,' said Gutmans, despite the fact that 75% to 80% of PHP users were developing on Windows workstations."

As a CGI you still have to make extra system calls that you don't have to make as an apache module. Running under FastCGI is a good first step but it still doesn't make it as fast as running it as an Apache Module. In a recent post on Slashdot about how Microsoft is learning from open source, they claim they made IIS more modular like Apache but this is not the case as PHP proves otherwise they could run it as a module.

I applaud the effort to embrace open source languages though and hope they continue along this path of self improvement.

In my testing (Perl, not PHP, but I don't think it particularly matters here), a "real world app" ran 98% as fast under FastCGI as under mod_perl -- and FastCGI is easier to deploy, easier to maintain, and (in the simple case) better on memory. Is it really worth chasing that extra 2%?

Of course, in the case of PHP, there's an extra incentive. I don't trust PHP's security or sanity for shit. So I'd much rather have it running in its own process with its own permissions than have it dynamically linked directly into my webserver:)

That is exactly the point. There are very few Windows deployments because PHP on Windows was 2-3 times slower than on Linux and unstable before we made the said improvements in PHP and Microsoft built FastCGI support into IIS 7.

But a language which uses this kind of thing, rather than a printf analogue with encoded type information is much more likely to encourage this kind of code. The PostgreSQL C interface contains a printf-like function which doesn't include the arguments in the SQL string at all, it puts pointers to arguments and the arguments themselves in the packet sent to the server so there is no escaping ever required because string arguments never go through the SQL parser. The same is true of most databases, and yet PHP still makes it easier to assemble queries as strings and throw them at the DB than use a sane interface.

I didn't mean to say American English has no rules. Only that English English has more, and that they are less logical and harder to remember. You're picking a grammar fight when I don't have Fowler's to hand, but from memory;

Singular with an s-ending takes word+'s
Plural without an s-ending takes word+'s
Plural with an s-ending takes word+es'
The United Nations (and other singular entities with plural names) takes word+'s

Between this and contraction forms, it's pretty obvious why apostrophes are dying out.

Zend is the PHP Company. I don't think it's any great secret that their aim is to monetize PHP. I'm not sure there's anything inherently wrong with that. Plenty of other companies and individuals monetize PHP by providing software, consulting, hosting and other services around PHP If there's value-add provided, companies will pay.

You're probably perfectly aware that there are a large section of Linux using shops who are perfectly happy to pay, hence the success of RHEL and to a lesser extent SuSE and now Ubuntu all of which offer support around free stuff.

The fact that Zend has worked with IBM on PHP for i5 (AS400) and with Microsoft for decent PHP on Windows only increases the choice of platforms PHP developers have to deploy on, makes PHP projects more popular across other user bases and means that PHP developers have a wider range of employment opportunities available to them. I don't think anyone is under the illusion that the future of PHP development is at 6 person consultancies who specialize in tweaking free CMSs, surviving on that free good stuff and creating pure karma (with no disrespect to small web consultancies intended, but it's a limited niche to attract new active members to the community).

If you'd like to spend your time pitching PHP as a strategic application development option to Fortune 500 companies, government departments and other enterprises, I'm sure we'd all be delighted, but there's not much chance of you spending your time doing that, nor quite frankly of those entities listening to you. They do however talk to Zend.

Zend isn't imposing a cost/tax on anybody or demanding that people pay homage/tribute, especially as PHP is a community project and not owned by Zend. During the past 2 years Zend has increased the amount of free and open source work they've done (Zend Framework and the Eclipse-based PDT) so it's not like they take and don't give.

If there is value companies can get from Zend's solution set, then they will pay for it. And they do. It's simple cost-benefit equations. WRT your "siphoning off revenue" if you look at all the companies in the Open Source space (including MySQL, EZ Publish, Acquia and other) they all provide value adds.

And yeah, I work for Zend. And no, you don't have to buy our stuff (but at least come check it out). And no the decision to monetize PHP wasn't made by executives on the fringe of the FOSS world, but rather technology people in the middle of it. (I have no idea whether they have hair up their asses like you claim - but can gladly inform you that that's not a sound basis for a business strategy unless you're a barber looking for a niche....)

PHP's issues with ISAPI are due to it not being thread-safe. We've tried to deploy PHP as ISAPI on windows, and things run fine until the customer starts using an application module that uses GD, or some other non-thread-safe extension, and then you get sporadic crashes that come more often as the load increases (which is obviously the worst time for a server crash).

FastCGI's benefit is that every FastCGI handler is still a separate process, so you don't run into threading issues, while at the same time not invoking the cost of constant process creation (which on windows is expensive), because the processes are reused.