> Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server.
I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends.
The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defaults to 1000 I believe), after a backend has served that many requests the process is recycled (an expensive and non-ideal operation on high load applications).
If you do a look around on Google you'll find this behaviour ships with PHP because of 'known memory leaks'. Rather than fix memory leaks the authors have opted to restart on an arbitrary number of requests. Does this sound like good design to you?
You think there's no application server because you've likely never worked on anything substantial enough to notice the silly string holding the whole mess together.
Well, if you're considering Apache+plugin to be an application server, then I guess I need to say: no additional application server other than the web server. Most modern systems have a web server and a separate process for the application server (proxied to over HTTP or fed by FastCGI or WSGI or a neat otherwise unused protocol). The standalone application server (back when I was mostly using those languages) always seemed to have a bunch of quirks and to fail at every insult. Compared to the Rube Goldberg nature of some of these stacks of servers and protocols, PHP is delightfully simple, conceptually.
> Compared to the Rube Goldberg nature of some of these stacks of servers and protocols, PHP is delightfully simple, conceptually.
I agree that what you could call it's deployment API (or whatnot), that it is very simple. I think the reason for it's success is it allowed HTML/CSS 'programmers' to progress to simple scripting within their existing deployment metaphor (upload via FTP, use a PHP file extension, wrap PHP in <?php tags).
However, there's no reason that you couldn't design a similar thing in say, Ruby or Python, where people upload files with a specific extention FTP and it runs some templating language (like ERB or Pythons equivalent). You'd need some web api to allow triggering reloads of files (or reloads on every request if the server is being used for development).
PHP out of the box re-parses _every single script on every single request_, which is what you'd expect a development environment to do, but 'in production' that's what PHP has always done.
Hence were born the optcode caches (which work rather well now), like APC. But still, on every request, every file that is required has a stat performed on it (you can turn this off, though).
It's all very lowest common denominator, and the high end stuff is severely lacking and poorly documented. It's possible to have the best of both worlds (well designed language, pragmatic libraries and toolset out of the box, simple deployment AND well defined high end high traffic considerations), but PHP ain't it.
However, PHP was designed from the outset to run in this mode so the interpreter is an order of magnitude faster than Perl, which is what competed with PHP back in 2001 -- PHP was ~designed~ through and through to do what it does, and that's why it does it so well.
I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends.
The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defaults to 1000 I believe), after a backend has served that many requests the process is recycled (an expensive and non-ideal operation on high load applications).
If you do a look around on Google you'll find this behaviour ships with PHP because of 'known memory leaks'. Rather than fix memory leaks the authors have opted to restart on an arbitrary number of requests. Does this sound like good design to you?
You think there's no application server because you've likely never worked on anything substantial enough to notice the silly string holding the whole mess together.