On Thursday 2008.10.02, at 23:00 , Vincent Nonnenmacher wrote:
[...]
I'm confused... What are your dashboard clients doing that need to
sustain 3 RPS (requests per second)? I.e., why do you need fast
updating for a dashboard app? It's not like this is some sort of
critical systems control panel (for e.g., an assembly line, nuclear
power plant, medical monitoring, etc.).
if you look at the breakdown of queues, having members, calls being
held, active calls coming and watching agents behaviour
you got that number as each one is making its own timed poll loop,
so this 3 req/s is on a 'small call-center'. As we do 'distributed'
queues handling on several servers, you double this when a dashboard
monitor two systems. Its true however that the size of the payload
will augment with the number of agents/queues with the same frequency.
There's certainly absolutely no reason at all to be making separate
requests for each piece of that information. I.e., you can easily
compact that down to a single bulk update request or, at the very
least, make each request over a single connection.
In terms of following multiple systems, again I'll recommend, if you
really care about scaling this to lots of clients, that you add a
"concentrator"/caching tier which would coalesce information from
e.g., multiple backend services/systems/etc. for efficient use by the
clients. This has so very many benefits, it's work to list them all.
So, in terms of your concern about the number of connections/requests
growing multiplicatively in the number of clients * systems, this
approach can again compact that down into a single client connection
to a concentrator/cache server and e.g., one single bulk update request.
BTW, a helpful way to think of the bulk requests is as a higher-level
publish/subscribe model (which is basically how Rob's solution for the
police works, the subscription is to the "event log"). The bulk
update request becomes: "give me every new 'event' since [the last
time I asked]".
On the AJAX client side, if you're going to progress beyond the 'fun
demo' level, you're going to need to switch to a clean, event driven
model in the client anyways to make it efficient, manageable, etc. and
that will actually make it easier for the web designers, eventually.
As part of that layer, your code bursts the bulk request and fires off
the appropriate AJAX events to update the DOM and the UI catches up as
it will.
Also, as mentioned previously, given that you're talking about human
scales of time for the dashboard, doing things like only polling once
per every e.g., 3 seconds instead of every second is a trivial way to
get a 3X reduction in load; having your AJAX be smart enough to
recognize when the user has moved their focus elsewhere and then
change the polling rate to e.g., every 30 seconds or 5 minutes will
have a large impact on your total systemic load since few people
actually follow these sorts of "nice to have" dashboards very closely
except for short periods of time; and as Jerome and Rob mentioned you
can use Conditional-GETs.
Let me also second Rob's conclusion that for "dashboard" uses that
require low, predictable latency that these HTTP based approaches are
NOT advised. I.e., if one is writing a control panel for something
where it really matters, the game is quite different and requires a
different mindset to build.
But it clearly show the limit of 'polling'.
Nope, it merely shows some limits of a simplistic approach. A polling
approach, even in this scenario can perform and scale quite well.
[ As an aside and mild rant, one of the biggest things I hate about
the zealous claims made by people pushing their latest fad (aka
'religion') in technical areas is that people see the simple, easy
stuff and then believe that their system can magically grow to handle
much larger, not so easy stuff without real thought and work. When
"it" fails to magically do that, people often get pissed off and then
claim that the whole approach is, a priori, bankrupt. ]
Doing long request polling will be far better (and in the easy reach
of Restlet) at the cost of a waiting thread on the Rest server, but
definitly a publish/subscribe mechanism like bayeux, will have a
more natural 'impedance match' than this approach.
You don't need Bayeux to do pub/sub nor do you need Comet to get e.g.,
lower latency. Comet ties up connections for very long periods of
time and can have its own issues if you're doing this over the 'net
(think about what the various intermediate proxies are allowed to do
to the connection).
I can quickly conclude that a generic console that will show you
all your company phones
status multiplied by the number of people watching them is a dead
end solution
(think about 500 users watching each other phones and how this
scale)
You should be able to update your resources on a periodic basis and
treat them as a cache between updates. I.e., don't do any
calculations on the requests.
its how I do it ad why the cpu load is not so important, but i was
concerned in the balance of expressing a clean REST syntax exposing
this representation and the fact that to limit the number of
requests, I will be obliged to pass along more 'collected'
information in a balance betweenI have take better Representation
vs number of requests.
Hmm... it sounds like you're falling into one of the classic REST
design blunders (that's just below starting a land war in Asia :-)...
It sounds like you're treating the REST surface area as basically a
flat space. The reality is that you can have multiple (levels of)
REST interfaces. I.e., build your low-level resources as you seem to
have already and then create a new, higher-level REST interface above
that which deals with the updates, bulking, etc.
For example in asking for a (phone/device/extension) status in order
to show a green/red light of a person availability and making a loop
asking for those elementary information and a plural (or list
syntax) in the query to have a long list of informaiton and then
express the loop inside the DOM manipulation.
Ah, I see. You're treating REST as a low-level, (cleaner) take on
RPC. I strongly suggest thinking of the client <-> server
communication at a higher level in terms of events.
Also, if you have lots and lots of connections to manage then you
can always add another, simple tier in front of the actual "master"
server to deal with the connection fan out.
Depending on what information you're passing back at the moment,
you should also be able to do bulking of requests... I.e., if
you're doing lots of small requests for individual pieces of data
you can create a much smaller number of requests for bundles of data.
You're absolutly right but at the expense of a more complex handling
on the client side. I wish I could have a so simple bunch of samples
that even a graphic designer could handle a complex dashboard using
copy&paste, without being too much concern about DOM manipulation (I
have found that web designers have difficulties with those 'empty'
DOMs document manipulated by some magicall javascript in front ;-)
As noted above, it's up to your connection management layer to cleanly
deal with bursting the bulk requests and sending out the appropriate
events. The client UI designers don't (and shouldn't!) ever need to
concern themselves at all with any of the connection issues. Going
the other direction (client to server) for special requests (i.e., not
part of the basic dashboard update flow that's automatically periodic)
the UI just fires off events that the connection layer listens to and
can handle immediately or do it's own bulking before sending to the
server.
Having the choice of being called by the server (or get a long
delayed response) will be much more easier on the REST syntax and
DOM manipulation by more web designers/programmers.
That's totally false. It's all about have a clean structure that's
event based. All of the ad hoc, simplistically programmatic AJAX
approaches fail under their own weight as the system gets to any
reasonable level of complexity. That's why the best AJAX frameworks
are all about making the event handling faster/easier/cleaner/etc.
As I've tried to point out, making a good, event-driven AJAX UI is
actually cleaner, more robust, and more responsive to the users than
the ad hoc approaches.
Hope this helps,
John
