That being said, 5000 requests per second is pretty low on any reasonable hardware. You can review github/robaho/go-trader - it does 30k requests per sec on desktop machines.
> On May 10, 2019, at 7:58 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > I don’t think your requirements are completely specified. For example, you > say the timeout is 100ms - nothing is ever exact - what is the tolerance in > the delay before it is cancelled ? Are the calls in the handler even > cancelable? What type of hardware (64+ cores?) > > I think this is why you are hearing crickets. > >> On May 10, 2019, at 7:05 AM, Nathanael Curin <n.cu...@capitaldata.fr> wrote: >> >> Good point on the implementing side of things, it's cleaner. I'm still >> really curious of the limits and implementation details - There has to be >> some kind of limit where things start to become erratic. If anyone wants to >> chime in :) >> >> Le jeudi 9 mai 2019 17:23:27 UTC+2, Burak Serdar a écrit : >>> >>> On Thu, May 9, 2019 at 9:03 AM Nathanael Curin <n.c...@capitaldata.fr> >>> wrote: >>> > >>> > Hi everyone, >>> > >>> > Searching Go's documentation and this group didn't really help me find >>> > what I'm looking for so, here goes. >>> > >>> > I'd like to implement a timeout system on every request to my HTTP server >>> > that would work like this : >>> > >>> > Receive an http.Request, perform initial checks on validity >>> > Start a timeout time.Timer of N milliseconds >>> > Send the Request + a context.Context to a goroutine, answering through a >>> > response channel when its job is done >>> > Wait in a Select for either channel (timer.C or responseChannel) >>> >>> You can use context.WithTimeout() for this. You can do: >>> >>> request=request.WithContext(context.WithTimeout(request.Context(), >>> 100*time.Millisecond)) >>> >>> and send the request to your goroutine. The context will be canceled >>> after the timeout. During processing, you should check if the context >>> is still alive and return if it timed out. >>> >>> Each timer will run it its own goroutine, so it'll take 2K of memory >>> for each. I don't know how accurate those timers would be, though. You >>> could record and log the difference between the time you start >>> processing and a timeout happens and see how well it scales. >>> >>> When the context times out, the select waiting on the cancel channel >>> will wake up, and then you can execute any cleanups necessary. A >>> timeout will not "unschedule" a goroutine, it'll simply close a >>> channel. >>> >>> > >>> > If the Select goes in the responseChannel branch, I can close my timer, >>> > and write my HTTP Response. Otherwise, my timer expired, I have to answer >>> > to my HTTP client, close my Context, and simply discard whatever is sent >>> > to the responseChannel afterwards, in the event that this actually >>> > happens. >>> > >>> > A few questions about this implementation : >>> > >>> > (Technical stuff) How exactly are Timers and Tickers implemented in the >>> > runtime / in the OS? Is there a hard limit? Soft limit? Is it CPU-bound? >>> > Core-bound?... >>> > If I received, let's say, 5000 queries per second, and every query has >>> > 100ms of timeout (so, 500 potential simultaneous timers - in practice, >>> > probably a bit more), would every timer really be perfectly stable? How >>> > can you make sure of this, debug, and monitor timer expirations? >>> > Last but not least, admitting that Go's scheduler actually answers >>> > perfectly fine at the timer's expiration, how can I make sure that the >>> > end of the code after the Select/Case runs without stopping? Can the >>> > routine get "unscheduled" after the timer's expiration, but before >>> > writing the HTTP Response for some reason? >>> > >>> > Thanks for the insight. Don't hesitate to ask for precisions if >>> > necessary. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google Groups >>> > "golang-nuts" group. >>> > To unsubscribe from this group and stop receiving emails from it, send an >>> > email to golan...@googlegroups.com. >>> > To view this discussion on the web visit >>> > https://groups.google.com/d/msgid/golang-nuts/cdf6b347-bfb9-44ce-b4d6-9d06602b1738%40googlegroups.com. >>> > >>> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/cccb64eb-2fc5-403e-a663-7f12996f1b38%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/F55588DC-4BC9-4D7E-9E33-AEC2929AA85A%40ix.netcom.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/76191CAD-4945-4E81-833D-2D9F99C4D6CD%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
