Here's a work in progress of mine that uses long polling and keep-alives.<p><a href="http://www.zchatter.com" rel="nofollow">http://www.zchatter.com</a><p>It works quite well.. pretty much like having a conventional tcp/ip connection for receives, (interlaced with HTTP traffic), and using a separate series of POST requests to send data to the server.
Has anyone experimented with a hybrid push/pull setup? If your data refreshes are bursty in nature, then this could be good idea, judging from the data in this paper. <p>Poll regularly for the server status using pulls, and in the event new data is published (start of a burst), initiate a push connection for a preset amount of time (this can be server controlled, depending on load). If the burst is not yet over after the thread is closed, it will just be resumed after the next pull indicates there is new data.<p>This setup would help minimize the mean time that threads are tied up, thus decreasing the thread pool size and server load. But again this is only beneficial if your data updates are bursty in nature.. <p>There is one thing this paper did not mention.. Unfortunately, due to browser security restrictions, AJAX calls must occur with the same server where the javascript originated. So this means when you are using a push setup and your server is beginning to max out, you are affecting the performance serving pages too! The HTTP keep-alive settings will keep those threads open for a while each time a page is served. Normally you can proxy and forward calls to other servers, but in this particular example the web server MUST maintain these open threads.. I think..<p>Just thinking aloud with this, but I'm interested if anyone else has comments.