

A Comparison of Push and Pull Techniques for Ajax [pdf] - damien
http://arxiv.org/pdf/0706.3984

======
axod
Here's a work in progress of mine that uses long polling and keep-alives.

<http://www.zchatter.com>

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.

~~~
jsjenkins168
Cool project. Do you maintain a blocking server thread for each connected user
(like TCP)? Any issues scaling when many users are simultaneously logged in?

------
jsjenkins168
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.

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.

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..

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..

Just thinking aloud with this, but I'm interested if anyone else has comments.

------
donna
Thanks, i know a couple of guys who will appreciate this. ;-D

