One other point, at 5k req/s sustained each request must on average complete in 200us (if using a single core) otherwise you will not make your deadlines and you will run out of memory. So 100 ms is way outside the threshold needed. Clearly by upping the parallelism you can increase the time interval but you get the general idea.
> On May 10, 2019, at 8:03 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > 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. -- 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/CCFBA3DB-0585-4FEB-8A50-BBECEF8B8FCC%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
