> I don't know, it seems a lot of the very high trafficked sites (Facebook, Yahoo) run PHP
I'm completely for PHP as a simple and accessible language. The previous author wanted to hear about the shortcomings of PHP and I tried to provide some. PHP sites such as Wikipedia probably need more servers (since every request is a separate process). They might be saving a lot of manpower by using PHP, so it might be an OK tradeoff.
By the way, Facebook uses Erlang for its performance-critical parts (such as chat).
> PHP is a share nothing architecture; each request is completely independent.
You could still use an agent-like messaging system for shared-nothing multithreaded/multiprocessed environment.
> I'd make more of a comment about the various PHP frameworks but "eventing system" seems kind of vague. Maybe you can clarify this a bit and then I'll comment.
e.g. When using cURL you must poll the handler until the request is complete. Obviously you'd need multithreading to achieve a better control flow in such a scenario.
> Nobody mixes in code & design in PHP anymore
I've written and debugged some wordpress plugins, and I can't say I came to the same conclusion as you...
> PHP sites such as Wikipedia probably need more servers (since every request is a separate process).
Citation needed. But every request isn't a separate PHP process; PHP is linked into Apache. Apache starts up a pool of processes and reuses them for requests. It's all highly efficient.
> By the way, Facebook uses Erlang for its performance-critical parts (such as chat).
Actually, it's not so much the performance critical parts but the parts where PHP's share-nothing architecture isn't appropriate. I doubt they're using a front-end web server for chat either.
> You could still use an agent-like messaging system for shared-nothing multithreaded/multiprocessed environment.
If you had the need, I suppose you could. Although I'm not sure what point you're trying to make here.
> When using cURL you must poll the handler until the request is complete. Obviously you'd need multithreading to achieve a better control flow in such a scenario.
You don't really need multithreading. JavaScript has callbacks for everything, for example, but isn't multithreaded. So this isn't so much a problem with PHP as it is a lack of design of cURL. But then cURL is a C library.
> I've written and debugged some wordpress plugins, and I can't say I came to the same conclusion as you...
Wordpress is old and not well designed. (Much like PHP itself)
Apache starts up a pool of processes and reuses them for requests. It's all highly efficient.
It's highly efficient if you have a small number of requests at any given time; It's not as efficient for peak hours.
If you had the need, I suppose you could. Although I'm not sure what point you're trying to make here.
There are several use-cases I can think of, the simplest being more than one blocking request for rendering your page, and using multi-process to reduce the latency to the maximal block time instead of the sum of all block times.
You don't really need multithreading. JavaScript has callbacks for everything, for example, but isn't multithreaded. So this isn't so much a problem with PHP as it is a lack of design of cURL. But then cURL is a C library.
Javascript on server environments needs solutions such as node.js. On the client side, well, most UI apps have a single UI thread and delegate jobs to worker threads. In javascript, these are usually done via XMLHttpRequests.
Actually it's quite fine during peak hours. You could, however, say it's a waste of resources during the lull times. But I'm not using those resources for anything else anyway; the entire purpose of the server is to service web requests. If a bunch of processes are sitting there wasting memory being idle, that's not a problem.
> There are several use-cases I can think of, the simplest being more than one blocking request for rendering your page
That's a fair case but I haven't personally encountered it yet. A good example, however, would be building a mashup page of content from a bunch of different web services.
It's true; many languages allow you to handle concurrent downloads by letting the OS call a function when the socket with the data is readable. (This is part of an "event loop".)
Many language implementations call this threading, however, because it is. You don't need one heavyweight OS thread for every thread of control in your application; many applications that make heavy use of IO easily handle thousands of threads inside one OS thread. It's a very useful abstraction.
I'm completely for PHP as a simple and accessible language. The previous author wanted to hear about the shortcomings of PHP and I tried to provide some. PHP sites such as Wikipedia probably need more servers (since every request is a separate process). They might be saving a lot of manpower by using PHP, so it might be an OK tradeoff.
By the way, Facebook uses Erlang for its performance-critical parts (such as chat).
> PHP is a share nothing architecture; each request is completely independent.
You could still use an agent-like messaging system for shared-nothing multithreaded/multiprocessed environment.
> I'd make more of a comment about the various PHP frameworks but "eventing system" seems kind of vague. Maybe you can clarify this a bit and then I'll comment.
e.g. When using cURL you must poll the handler until the request is complete. Obviously you'd need multithreading to achieve a better control flow in such a scenario.
> Nobody mixes in code & design in PHP anymore
I've written and debugged some wordpress plugins, and I can't say I came to the same conclusion as you...