Hi All, Just thought I'd let you know how I went with the rate limiter. After several searches on Google about why rate limiter does not generate events at the rate I requested, I hit on the following issue on Github and saw this comment from Chris Hines about setting a burst value equal to the limiter limit i.e. if the desired rate is 2000, then set burst to 2000 as well.
https://github.com/golang/go/issues/47084#issuecomment-897291261 With this change to my code, I was able to get events generated at the rate I specify i.e. if I configure my application to generate 1000 transactions per second (TPS), I get 1000. If 5000, then I get 5000 etc. It appears this is something to do with the change to the netpoller sleep interval granularity being 1ms on linux. For now, I am able to generate transactions at the rate I specify, so I am in a much better position as of now - with no loss of TPS. On Friday, 4 February 2022 at 17:27:43 UTC+11 envee wrote: > Uli, Robert, > I finally settled on using the rate limiter package to achieve what I > need. I have a machine with 40 vCPUs and when I use a rate limiter with a > rate limit of 1000, I am able to generate HTTP requests at that rate. > (There are other processes running on this RHEL 7 machine, but it is very > lightly loaded). > > When I increase the limit to anything higher than 3000 TPS (transactions > per second), my program can only generate 1000 TPS less than that rate. > For example, if I need to send 4000 TPS, I can see (using some custom > Prometheus metrics), that I am generating only 3000 TPS. Likewise, if I set > the limit to 8000 TPS, I can see request rate of 7000 TPS. > I can live with that for now. Because atleast I have a mechanism to > control the rate and get close to what I need. > > I will see if I can tune my program any further to get much closer to the > desired rate. > > Thank you all for your help. > > On Thursday, 3 February 2022 at 19:05:02 UTC+11 Amnon wrote: > >> > 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 <ren...@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....@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...@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...@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/3cf90126-e41f-4514-85ab-c4d4cf3da859n%40googlegroups.com.
