Submission Throttling and the Browser-Server Dialogue
The second part of this series of articles dealing with browser-server information flow discussed periodic refreshing. This one covers submission throttling and explicit submission. The third of a multi-part series, this article is excerpted from chapter 10 of the book Ajax Design Patterns, written by Michael Mahemoff (O'Reilly, 2006; ISBN: 0596101805).
Submission Throttling and the Browser-Server Dialogue (Page 1 of 7 )
Buffer, Queue, Performance, Throttle
Figure 10-4. Submission Throttling
Devi's producing an Ajax chat web site and wants to transmit text as the user types. However, she knows some users will type faster than the system can cope with so she introduces a throttling mechanism that ensures no more than one message is uploaded every 200 milliseconds.
How can information be submitted to the server?
Information is often uploaded in bursts; e.g., a chat tool incurs many hits when a user becomes passionate about the topic, or a data entry tool incurs many hits when the user responds to some new information.
It's difficult for the server to cope with lots of messages at once.
Browsers can only handle a limited number of pending XMLHttpRequest Calls at any moment.
Each message has overheads, such as packet headers and requires some processing at each stage of the browser/server round-trip.
Exactly what the buffer holds is application-specific, but there are two general styles: data buffers and command queues.
In the first buffer style, the buffer holds some data to be uploaded. Consider implementing a Suggestion (Chapter 14) interface like Google Suggest (http://www.google.com/webhp?complete=1&hl=en), which keeps showing information based on what's been typed. The simplest thing would be to add an "onchange" listener to the text field and upload the buffer when each change occurs. However, what if you get a fast typist, one of those folks who revels in their "words per minute" metric? Banging out 100 words per minute means perhaps 10 characters per second, or a call every 100 milliseconds--feasible with a local-host web server, maybe workable on an intranet, but not scalable for most public Internet applications. So Suggestion systems, and more generally Live Command-Lines (Chapter 14), run a fixed-period timer. Every 500 milliseconds, say, the browser checks if there was a change since the last call, and if so, uploads to get some information and remembers what was uploaded to avoid doing so again. Effectively, the result for the current text field is cached, and the cache can only change on fixed periods.
A similar pattern might be used on a Live Form (Chapter 14), where the entire form is periodically uploaded to the server, even though some fields are blank, along with an indication of the user's progress. The server can then use some intelligence to critique the form data, so as to provide live feedback.
Submission Throttling might appear to optimize technical resources at the expense of usability, but can actually be a boon for users too. There's a reason why the Windows and Apple operating systems don't show copious logging details when booting. Technical users may appreciate the comprehensive output of a Linux boot sequence, but most users consider it overload--much more information than they actually care about. Throttling is a good way to prevent information overload in the browser, especially error messages that might come back because the user is only halfway through an edit.