Web browsers don't "pick a random sleep time before trying again", though; they display a 500 error page and the user promptly clicks "reload" while making an exasperated sigh.
If the client is something other than a web browser, then we're no longer talking about the web, but some other thing, like SMTP or whatever. And then we're outside the scope of my earlier remark, which specifically mentioned the web. Not to mention outside the scope of the OP's product, which was clearly referred to as a "Ring middleware" and not some other sort of server component for some other kind of server. Or were you meaning to suggest that the *users* pick a random sleep time before trying again? Good luck herding them cats. See also http://en.wikipedia.org/wiki/Wicked_problem ... On Sat, Nov 16, 2013 at 4:24 PM, James Reeves <ja...@booleanknot.com> wrote: > 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. > -- -- 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.
