Push vs Pull

The Ajaxian has covered a study of push vs pull Ajax  communication techniques. The original report was produced by Delft University. I welcome this report as a good start on objectively measuring the communication techniques needed for web 2.0 applications, but unfortunately the report contains a couple of minor misconceptions and is somewhat misdirected in the type of application studied.

One minor misconception is that long polling and the bayeux protocol disconnect between long polls.  While it is true that long polls return if they are idle for a period, the underlying TCP/IP connection is kept open and no reconnection is needed.  The HTTP response and new request sent just keep the connection open, just like the heart beat messages sent over a streamed connection.  The only cost is some small additional latency for events that occur while the long-poll is being renewed.

The report also could be read as implying that the bayeux protocol is only long polling. While long polling is the default, it can also support polling or streaming.  In fact with clever use of timeout settings, bayeux can support a combination of polling, long polling and streaming (credit to Joe Walker of DWR for this idea). A client can pause between requests (normal polling), the server can hold onto a request while waiting for an event (long polling) and then keep the response open after an event (streaming).  This is not yet fully implemented, but the protocol certainly allows this and other transport techniques.

Other than this minor issues, the main issue I have with the report is that it does not include event latency as a degree of freedom.  The pull implementation they test has a 15 second period, which means that events will have an average 7.5 second latency for a perfect implementation.   While there are many many applications that can live such latency (or longer), they are not the target applications for Ajax Comet techniques.  A  15 second latency is simply too much for chat, for collaborative editing, for help line operators manipulating the pages of calling clients, for gaming and for the applications that have not yet been thought of that can take advantage of low latency client server, server client messaging.

So while the report finds that long polling can take 7 times more CPU that polling, if the polling period was reduced from 15s to 1.5s to provide low latency, then the CPU usage for polling would be increased 10 times.   (More over, I think the 7 times figure is at least partially due to an early implementation of Bayeux and a buggy release of jetty).

To be realistic, as well as varying the event rate and the number of clients, the study should have varied the target latency.  For applications that can tolerate long latency, then push/comet techniques are probably not applicable and polling is an ideal and efficient technique. (this is NOT to say that the bayeux protocol and messaging paradigm is also not applicable for low latency).

As the required latency is reduced,  there will be a cut over point where push is more efficient that pull.  However, that cut over point will depend greatly on the message rate, the message distribution over clients and the message size.

So while the Delft report is a welcome first data point, it is only a single data point in a wide spectrum of application load profiles.  I hope they follow up with more broadly based studies (or lend me their super computer to do the same 🙂