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!
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.).
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.
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.
Hope this helps,
John
