Hey Rob,
Thanks for the wonderful example!
A couple of points extra credit points come to mind... :-)
On Friday 2008.10.03, at 08:38 , Rob Heittman wrote:
[...]
In my app, the poll interval is self-throttling and not
deterministic; a client begins a new poll after the last poll
completes, plus any configured delay. As John said, instant updates
may not be needed; a second or three may be an acceptable delay
between UI updates.
Well, just to hammer this issue into the ground... If humans are in
the control loop and we're not talking about a truly hard-realtime
system such as a flight control system then 1 second *is*
"instantaneous" and 3 seconds is "immediate". I know that dashboards
have been the rage for the last few years but I just don't see many of
them that have any sort of really serious, low latency constraint *in
reality*. Heck, there's not much value in most of them over an RSS
feed (and don't get me started on crap like twitter), other than the
pretty colors and charts but I'll stop being mean. :-)
This design ensures that eventually every client will see every
event, but there is no realtime or near-realtime guarantee. The
faster/better the client computer, the closer to realtime its
performance.
But that will also increase the unnecessary load on the servers.
Have you thought of changing from using an "extra delay" to a "period
length" approach? I.e., rather than doing your best effort work on
the client and then adding a fixed length delay (i.e., 1 second), you
can make the update period e.g., 3 seconds. I.e., the client updates,
however long that takes and if it's less than 3 seconds since the last
update just wait until the 3 seconds have expired and then do the next
update, if the client is taking longer than 3 seconds to update do the
next request immediately (and suggest that the user upgrade their
system :-). By knowing the latter case is happening, you can also
think about implementing extra smarts by doing things like coalescing
multiple updates to the same UI item, suspending other non-essential
things in the system, increasing the period length, etc.
This approach keeps the loading on the servers more consistent and
thereby frees up resources (sockets, conditional GET checks, etc.) and
provides better/more efficient utilization of the bulking of updates.
Rock on,
John
