Earlier quoted context omitted.
> 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 t…
> 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 cri…
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.