On 16/11/13 22:06, James Reeves wrote:
I can see overload-middleware being useful in an internal network,
where clients are submitting jobs to a central server. The clients can
be programmed to wait a random length of time before retrying if the
server is overloaded. I suspect that a better solution might be to use
a queue, but it really depends on the requirements of the system being
developed.
Yes, this is the context in which I learnt about this approach to
overload handling - one of the projects I work on is basically a simple
HTTP interface to a more complicated protocol server (DIAMETER), with
some database caching. It provides subscriber data to a VoIP server, so
there's no direct user access to it - the "user interface" is a phone
(or Skype-like program).
Queues are also a good solution in some cases, and we use them elsewhere
- but you do need to tune your queue length to get the performance you
want. The principle here is that you provide a target latency, and your
"queue length" (actually the refill speed of your token bucket) gets
automatically tuned to meet it.
(I probably caused some confusion initially by saying "web apps" - I
should have said "HTTP services" which is what I actually had in mind.)
Rob
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
