John D. Mitchell a écrit :
On Thursday 2008.10.02, at 01:25 , Vincent Nonnenmacher wrote:
[...]
I've choosen first to implement an ajax inerface to it for
demonstration purposes
so I quickly wrote several Quick&Simple samples using jQuery.
Cool!
thanks to jQuery & Restlet, sure having a 20 lines of javascripts and
total freedom for
web developers to make their own phone dashboards will be a plus.
But looking at the bandwith used by exchanges between client and
Restlet server I quickly see the limits
for this 'polling' approach (for example a simple queues management
console for monitoring several asterisk
servers's calls queues are around 3 request/s and even if each grab
1-5 ms of time
to serve the approach will push linearly on the server as the client
augment * by the polling frequency)
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.
But it clearly show the limit of 'polling'.
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.
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.
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.
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 ;-)
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.
