It may be useful for certain web services. If the server gets overloaded by a temporary spike, the clients could pick a random sleep time before trying again.
- James On 16 November 2013 21:15, Cedric Greevey <cgree...@gmail.com> wrote: > I can think of very few web apps where this would be a desirable approach. > A user getting a spurious error in response to a URL that they *know* is > valid is just going to hammer on the "reload" button until they get a > correct response from the server. So the server will end up even more > congested than if it just responded sluggishly but otherwise normally to > the request. > > > On Sat, Nov 16, 2013 at 1:21 PM, Rob Day <r...@rkd.me.uk> wrote: > >> Hi all, >> >> I've just published the first working version of a Ring middleware that >> some of you might find useful. It's designed for web apps where, if you're >> overloaded, it's better to serve some requests quickly and fail the others >> than to try and serve all the requests and do it slowly. (My background is >> in telecoms, where that's often the best approach.) >> >> Specifically, you specify a target latency that you want 90% of requests >> to try and meet, and it applies the algorithm from >> http://www.eecs.harvard.edu/%7Emdw/papers/control-usits03.pdf to try and >> keep your latency below that threshold. The exact parameters of the >> algorithm are tunable, and different URLs or groups of URLs can have >> different targets and parameters. >> >> It still needs a bit of tidying - docstrings, cleaning up some of the >> Midje tests, and so on - but it works and I think the documentation is >> usable, so I'm announcing it now. >> >> Github (w/ docs): https://github.com/rkday/overload-middleware >> Clojars: https://clojars.org/overload-middleware >> >> Let me know if you have any feedback! >> Rob >> >> P.S. I threw together a simple demo (available from >> https://github.com/rkday/overload-middleware-demo) and tested it It >> works as designed - the URL wrapped in the overload middleware fails about >> 50% of requests, and so for the ones that succeed there's a noticeable >> speed improvement (80% of results are served in 120ms as opposed to 233ms >> for the unwrapped URL), though I suspect ab might be counting the immediate >> 503s in this result and throwing it off. If anyone has ideas for better >> tests, let me know! >> >> 2049 14:05:02 overload-demo $ for i in unwrapped wrapped; do ab -n 50000 >> -c 300 -q http://localhost:3000/$i; done >> ... >> Document Path: /unwrapped >> .. >> Failed requests: 0 >> ... >> Percentage of the requests served within a certain time (ms) >> 50% 178 >> 66% 204 >> 75% 216 >> 80% 233 >> 90% 358 >> 95% 1117 >> 98% 1211 >> 99% 3097 >> 100% 15196 (longest request) >> >> ... >> Document Path: /wrapped >> ... >> Failed requests: 25285 >> (Connect: 0, Receive: 0, Length: 25285, Exceptions: 0) >> Write errors: 0 >> Non-2xx responses: 25285 >> ... >> Percentage of the requests served within a certain time (ms) >> 50% 67 >> 66% 86 >> 75% 108 >> 80% 120 >> 90% 1028 >> 95% 1080 >> 98% 1287 >> 99% 3082 >> 100% 15120 (longest request) >> >> There's also no noticeable overhead in non-overload cases: >> >> 2050 14:07:30 overload-demo $ for i in unwrapped wrapped; do ab -n 50 -c >> 1 -q http://localhost:3000/$i; done >> ... >> Document Path: /unwrapped >> .. >> Failed requests: 0 >> ... >> Percentage of the requests served within a certain time (ms) >> 50% 33 >> 66% 33 >> 75% 33 >> 80% 33 >> 90% 33 >> 95% 34 >> 98% 35 >> 99% 35 >> 100% 35 (longest request) >> >> ... >> Document Path: /wrapped >> ... >> Failed requests: 0 >> ... >> Percentage of the requests served within a certain time (ms) >> 50% 33 >> 66% 34 >> 75% 34 >> 80% 34 >> 90% 34 >> 95% 34 >> 98% 34 >> 99% 34 >> 100% 34 (longest request) >> >> -- >> -- >> 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. >> > > -- > -- > 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. > -- -- 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.
