> From the tests that I have performed, I can see that a Ticker pretty accurately fires at every 1ms interval.
It will depend on the load on your machine. As the load on the machine increases, so with the jitter in the tick time. On Thu, Feb 3, 2022 at 1:19 AM Robert Engels <reng...@ix.netcom.com> wrote: > I am unclear why you need to use an N of M. I would make sure the hardest > case is handled and you can use a variety of techniques to partition the > work. > > On Feb 2, 2022, at 6:58 PM, envee <neeraj.vaidy...@gmail.com> wrote: > > And I forgot to mention that approach I mentioned talks about waking up N > goroutines at a time. The way I plan to do is to select a range of N > goroutines from my list of goroutines and only allow those goroutines to > send HTTP requests. > I could use this approach to select the N goroutines or even use a > Semaphore. I presume using a Semaphore, will allow a good amount of random > N goroutines out of M goroutines to execute. > > On Thursday, 3 February 2022 at 10:26:28 UTC+11 envee wrote: > >> Thanks Robert, Uli and Ian for your suggestions. >> >> I think what I will probably do is use a Ticker with a duration of 1ms. >> At every 1ms, I will "wake-up" N number of goroutines to trigger HTTP >> requests. >> That number N = (request rate per second / 1000) = requests per ms. >> So, if I need to ensure a rate of 10000 requests per second, I believe it >> should be possible for the Ticker to return after every 1ms and then fire >> about 10 requests at every such interval. >> From the tests that I have performed, I can see that a Ticker pretty >> accurately fires at every 1ms interval. >> I think it's only when the Ticker duration falls below 1ms, that I see >> issues. >> >> If my desired rate is less than 1000 per second, then I will create a >> Ticker to return every 1000/request rate milliseconds, which will be a >> number greater than 1ms. >> >> This approach is closely based on Robert's suggestion about using a >> higher duration for Ticker time and waking up a small subset of goroutines. >> >> I think it should be ok for a client to be accurate at the level of >> granularity of 1ms. >> >> >> On Thursday, 3 February 2022 at 01:14:20 UTC+11 ren...@ix.netcom.com >> wrote: >> >>> Because 20000 is a magnitude larger than 2000. >>> >>> > On Feb 1, 2022, at 1:44 PM, Uli Kunitz <uli.k...@gmail.com> wrote: >>> > >>> >> -- > 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/209b18aa-1317-4d72-80a1-222f10a26013n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/209b18aa-1317-4d72-80a1-222f10a26013n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/3GUnjdoWjqU/unsubscribe. > To unsubscribe from this group and all its topics, 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/F912EE7E-4F80-4C16-ABC1-943572FD576C%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/F912EE7E-4F80-4C16-ABC1-943572FD576C%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- 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/CALg-z3VpSw1dJwbn4YDd98qJsfj_NtSDJUrsA3p2xk%2BzQMChuQ%40mail.gmail.com.
