On Friday 2008.10.10, at 03:06 , Vincent Nonnenmacher wrote:
John D. Mitchell a écrit :
[...]
Also using queuing tricks (like the ones available on jQuery and
Dojo also help without too much complexity on the client code. I
came down now to 1 req/s monitoring two servers and a dozen of qeues/
members. As the requests are chunked and finally displayed in a
aggregated <DIV> tree, the match between receiving a pre-digested
structure and DOM building is on par, so the event to DOM
marshalling is quite natural.
That's great!
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.
my server does exactly that on the asterisk servers side, so there
only one connexion for a lot of clients to one of the server
distributed 'abstraction' (in fact it is where the 'innovation'
really goes ;-)
But this doesn't solve the 'too much/too often' requests when using
even 'subtle polling' techniques
for solving the asynchronous/synchronous problem giving a close as
possible 'real time' feeling.
Sure it does. It's a quality of service issue. If you want faster
polling you have exactly the levers that you need to increase:
increase your polling rate to 2/sec and increase the number of cache/
concentrators as appropriate to control the server side response
latency. Now you're so far within normal human perception time that
it's a joke for 99+% of the people in the world. Now you've got a
simple solution to your problem that's more portable, doesn't add any
new complexity or different code paths, etc.
In fact the only area in telephony where customers want to feel
'real time' is the time between hearing their phone ringing on the
desk and seeing who's calling (even when working in openspace,
'who's calling my buddy phone'. If you solve that subtle feeling
with a quick display reaction, they will excuse a certain amount of
latency in further display adjustment (like seeing that a phone goes
from ringing to answer, or a queue member status been updated
somewhere else).
You're talking about human reaction times between (a) working on
something and then (b) hearing the phone ring and then (c) looking
over to the phone or dashboard to then scan for e.g. Caller ID
information. A 1 second gap is trivial in that usage. It's even more
trivial if you also account for the time that it takes for a normal
human to reach over and pick up the phone while/before looking for the
Caller ID information.
FWIW, a better argument would be something like a trading system but
you'd still lose since anybody who really cares about those kind of
latencies there has to get humans completely out of the critical fast-
path anyways and there are still race conditions at the matching site,
regardless. :-)
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.
yes it helped, even if I don't know how to monitor what you call
'user attention',
When your dashboard e.g., loses the focus then the user is most likely
doing something else.
but I'm considering also a estimation of call activity where I could
gradualy slow done refreshes during period where there is no phone
activity at all. Using a queue for ajax requests it will be easy to
throttle the load of unnecessary requests as the server could
provide such an running estimate.
Hmm... Why would you care about optimizing that case? If the system
has little load then all of the requests will just hit the cache (and
not-modified checks). The case where you would need a slow down from
the clients is when the server is overwhelmed (and that's a good bit
of information to get automatically since that's gong to tell you to
add more server, concentrators, bandwidth, etc.).
[...]
Would it be so awfull to have two such (PUBLISH/SUBSCRIBE) verbs
added to the REST actions ?
After all even if the http don't include them (yet) it is a
logically wrong inference to tied the actual
transport instead of grasping that the protocol pattern is 'just' a
request/response one (synchronicity here is only
a modality, not the whole point).
Depends on which branch of the REST world you fall into. The REST
purists take e.g., the statelessness issue a long way and can easily
make the argument that the existing REST approach can (logically)
handle the pub/sub thing without any additional verbs: subscribe by
e.g. POSTing to a signup resource giving it a URL to "publish" the
notifications to. This is already doable today and is a
pure/"correct" REST solution. The problem are the real world
constraints that people have in the HTTP infrastructure w.r.t.
routability and security. Comet is a technical hack to try and get
around that limitation that the "client" has to initiate all
discussions because of those constraints.
Take care,
John
