From: Walden H. Leverich
Take a look at the way facebook does chat ...
I monitored a Facebook chat with Fiddler. And I kind-of get the picture. They use one URL to send messages. But a different one to receive. The receive will wait for about 1 minute for a new chat message before recycling. One nice part about this is that new messages are received a moment after being sent, rather than the typical 5-15 second delay of polling.
In Facebook, it looks like a PHP script handles the send. But I don't think you'd want to use PHP, or any other type of CGI process that would tie up an HTTP server thread for up to a minute on a receive request.
One unspoken rule of CGI is to limit the number of active HTTP server threads. Some PHP administrators recommend a maximum of 100 threads per CPU. Since PHP is a rather big application, you wouldn't want too many instances active - too much memory.
The same rule applies to J2EE application servers. You don't want too many instances of a Servlet active. But I followed up on Thorbjørn's point about using suspend-able requests to free up threads while Servlets are in a wait state. That way you could configure the HTTP server to run say 10,000 threads, but the application server to run say 200 threads. So I gather that the HTTP server could hold the connection, while application server threads are in a wait state, allowing others to be active.
Maybe Facebook is using PHP to handle sent messages, but Jetty to handle received. Who knows?
Anyway, thanks for the suggestion to look at Facebook. From a usability perspective, I like that messages are received only a moment after being sent. I may try something like that, when I get around to writing a chat application.
Nathan.
midrange.com
