Bio not provided
I guess it's time for you to run a benchmark with a "true" PHP application behind it :)
And let us know what version of nginx you're using... I'm using mostly 1.4.3 and 1.4.7 (I have no idea if there are substantial performance issues between them, the changelogs show mainly bug fixes and security patches)
2 weeks, 2 days ago on Performance of Apache 2.4 with the event MPM compared to Nginx
Hahaha :) I loved reading this old article of yours; maybe one day I'll start sending links to it to those people who pester me about PHP...
I'm sure that some of your readers here are professional developers with a decade of experience and who learned Java (and perhaps C++) at university. Well, I'm an old girl, and while in my days the Internet already existed, there was no Web, and obviously no PHP. C++ was the most complex language we were expected to learn, and pretty much everything that academia had developed in terms of conceptual frameworks on how people ought to programme was then "ported" to Java.
When the Web gained CGI, the languages of choice were Perl, and, obviously, plain old C. CGI was rather hard to configure at the very beginning when it was a novelty. Soon afterwards, PHP made its debut, and, as you so well put it, it was ridiculously easy to use. Variables being used without being declared? No strong types? Oh yes! We could immediately throw in some code and get things done easily, instead of having to write behemoths with thousands of lines of code (like in Java and C++) just to get something that actually compiles...
Obviously I'm quite aware of the limitations of PHP, and why strong typing and all the other nifty features from other programming languages are so important, specially in a multi-developer environment. But the point is that PHP is _cool_ to programme in, and you can start from scratch with a handful of lines of the most horrible code, which already does something useful, and then improve it to make it look better.
Fortunately, I'm not a professional developer, and mostly "programme to get things done" — which often includes getting different technologies to talk to each other and offering REST-based APIs to encapsulate all the mess beneath. The easiest way to do that is to have PHP at the top. I'm not saying it's the "best" way. It's just the "easiest" way. My current work is exactly to hide the complexities of a net-based (but not web-based) C# application, by throwing a PHP-wrapper on top of everything. Then I can develop my remaining application logic on PHP, embed it as a WordPress plugin, run it from the command line as a simple PHP CLI script... whatever. It's so much easier. Ugly? Perhaps.
One nice thing about PHP applications is that how they're so neatly isolated from each other in a common environment, because, ultimately, from the webserver's perspective, they're just files on disk which communicate to the outside world through the webserver. Recently I had a wonderful Python application running on a subdomain — lightweight, very fast, compact, with all the bells and whistles. Then people liked it so much that they wanted several instances of that application working on the same server, under different domains, so that they could isolate user groups neatly. Uh... right. That started to become impossible — the application was designed to run as a single instance. You could run it on different ports, then throw in a port redirector in front of everything, and... well, you can imagine the mess. I had gone through that tons of times before with Java applications — if they haven't been designed from scratch to run as multiple instances, it will be a nightmare to do that. Obviously there are tricks: you can create virtual machines, each running an instance, for example. Messy!
With a PHP application, all you do is to copy the files from one directory to another and have your webserver point a virtual host to it — and, there you go, you get a second instance. No fuss. No overhead. No incompatibilities. Couldn't be easier!
Obviously PHP's most visible limitation is that it doesn't work nicely outside a Web environment. A company I used to work with tended to ship their PHP application with a whole server around it (a Mac mini!) — it was far easier to develop, maintain and support customers that way, and have whole companies just use any browser to access their PHP application, instead of developing a Java/.NET/whatever traditional client-server application. In fact, I still have nightmares from working as a consultant for companies that had those kinds of client-server juggernauts running the business logic of their companies, with huge maintenance issues, as each desktop computer needed to be _exactly_ the same to make sure the application would work fine — but of course there would be always someone from the Board who would be issued a non-standard laptop, and the time to maintain that would quickly become a nightmare. While native applications on the desktop can certainly leverage performance (specially as web browsers get more and more bloated...) far better, and developing a front-end (on the desktop) and back-end (on the server) using exactly the same language (say, Java, C# or Python) is far easier for programmers, in the "real world", I really prefer maintaining and supporting PHP on the backend — and just have anyone in the workplace point the browser on their Internet-connected device (whatever it might be — from Blackberry to a gamer's PC) to an URL.
Still, it's quite true that PHP programmers are not exactly seen as "real programmers" (because PHP is not a "real language" — hey, it just has _arrays_! Where are the double linked lists, the B* trees, the hash/sparse tables...?) In fact, almost two decades ago (PHP was still very young back then!), I got fired when trying to add a PHP wrapper on top of a proprietary Oracle database running a public library. The issue back then was that they just barely managed to get 7 terminals connected to the mainframe back then. I proposed to use one of the 7 to run Apache + PHP, interface with Oracle, and export the results through the Web to anyone who could install a web browser on their networked device (and yes, some people even used text-based web browsers back then, on ancient VT100 terminals!). It was seen as "too revolutionary" back then, of course. But even today — even though PHP programmers can get jobs easily enough! — as soon as an organisation starts to "get serious" about what they're IT infrastructure is supposed to look like, PHP gets dumped in favour of one of the other "serious" programming languages. I see that happening all the time.
Because I'm _very_ biased, all I can see is that ugly-but-doing-the-job PHP applications with a few hundreds of lines get replaced by behemoths in Java which take years to develop, and, while they have flawless coding and expert developers behind them, they require oogles of more computing power to achieve pretty much what the poor, old, ugly PHP application did. Well, I guess that this makes the hardware business grow, which is not bad. On the other hand, I see way too much sloppy programming on the so-called "serious programming languages" that I always wonder if it's worth making the change... PHP is sloppy by nature, but designed to handle sloppyness well and efficiently. I can't say the same about the other programming languages...
I would say that PHP _does_, indeed, appeal to sloppy and lazy programmers, who just want to get things done quickly and efficiently. That is one of the reasons why I believe it gets so little credibility from "real" programmers. Specially real programmers who work at Google or Microsoft — no wonder, thus, that they take so long to embrace PHP...
Even though I have seen Microsoft reps firmly stating that PHP is, indeed, a Microsoft-supported language. Or they wouldn't be able to support their WordPress-enabled blogs on MS Live...
2 weeks, 2 days ago on Google finally acknowledges that PHP exists