You rule :)

Kudos, you really know your php.

The problem with continuous connections to the server is that N simultanious clients (not unimaginable on an application server, such as a chat server, or an rss reader) would require at least 1.3 x N connections, so it doesn't scale that well on Apache.

How would you work around that problem? I was thinking of running a small-footprint, basic web server (in PHP, Python or C) that could be run in 2000+ threads (or handling a number of clients on a single thread, whichever is more efficient) continously serving clients PHP-generated, cached data (think 'tail client-632223.js').

I don't know what are the technical limits on the server OS side, but with Ajax-y websites sprouting everywhere, this kind of framework could prove handy.

Yes, I have not yet needed to keep connections for a long period, but in some cases that is really a concern.

First, regardless if whatever is on the server side can scale well or not, I think that in most cases you do not necessarily need to keep permanent connections forever.

For instance, when an user in a chat room that becomes idle, you may disconnect him for a while and reconnect when he becomes busy, and poll the server once in a while for any pending messages while the user remains idle.

As for the Apache based solutions apparent scalability limitations, I think it is not so much on Apache or PHP, but rather on specific PHP extensions and libraries that PHP depends that are not thread safe. I think the big question is: which PHP extensions and libraries are safe?

If you only use other extensions, you can run Apache 2.x worker with PHP. Alternatively you can run PHP with FastCGI and any multithreaded Web server known to have a low memory footprint, maybe thttpd or lighthttpd .

I understand that CGI based applications add a little overhead, but depending on the AJAX application you want to implement, maybe that overhead is not noticeable to the user waiting for the information to arrive.