Hi, thanks for sharing! I noticed some issues with your code and try to suggest a solution here. Talking about the design of this rate limiter, I'd say it's rather a 1 request per 100ms than a 10 req/sec rate limiter, as you can see in a slightly modified version here:
I use time.Since() to calculate when a request is handled. You see in the output that every 100ms a request is handled. If that is the desired behaviour, it's fine. On the other hand, using this solution, coping with peaks in the requests is not possible. For example doing 5 requests concurrently still requires 500ms, although there should be 10 per second allowed.
In addition, memory from the rate variable is never cleaned up. That's not a problem here (because it's a global variable and lives until the program does), but I just wanted to mention it.
packagemainimport("fmt""sync""time")varlimit=10varrate=time.Tick(time.Second/time.Duration(limit))varstartTime=time.Now()funcmain(){totalRequests:=100varwgsync.WaitGroupwg.Add(totalRequests)// Rate limit to 10 requests per secondfori:=0;i<totalRequests;i++{gofunc(iint){deferwg.Done()sendRequest(i+1)}(i)}// Wait until all request are completedwg.Wait()}funcsendRequest(iint){<-rate// Wait for the next tickfmt.Printf("Completed request %3d at %s\n",i,time.Since(startTime))}
I done a slight refactoring using the token-bucket rate limiting approach with channels. The bucket is a buffered channel with 10 entries and every request receives a token from it. In another goroutine, the bucket is filled by 10 items every second. If there is no token left, the request blocks until it's filled up again. This solutions handles peaks very well as you can see in the output. A batch of 10 requests is handled the same time and then everything waits for a second.
packagemainimport("fmt""sync""time")varlimit=10varbucket=make(chanstruct{},limit)varstartTime=time.Now()funcmain(){totalRequests:=100varwgsync.WaitGroupwg.Add(totalRequests)gofunc(){for{// the bucket refill routinefori:=0;i<limit;i++{bucket<-struct{}{}}time.Sleep(time.Second)}}()// Rate limit to 10 requests per secondfori:=0;i<totalRequests;i++{gofunc(iint){deferwg.Done()sendRequest(i+1)}(i)}// Wait until all request are completedwg.Wait()}funcsendRequest(iint){<-bucket// get "token" from the bucketfmt.Printf("Completed request %3d at %s\n",i,time.Since(startTime))}
@davidkroell thank you for your incredibly useful reply.
You're right. My solution may be suitable in some cases, but if the goal is to perform many requests concurrently while maintaining a specific rate limit, then your solution is excellent.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, thanks for sharing! I noticed some issues with your code and try to suggest a solution here. Talking about the design of this rate limiter, I'd say it's rather a 1 request per 100ms than a 10 req/sec rate limiter, as you can see in a slightly modified version here:
I use
time.Since()to calculate when a request is handled. You see in the output that every 100ms a request is handled. If that is the desired behaviour, it's fine. On the other hand, using this solution, coping with peaks in the requests is not possible. For example doing 5 requests concurrently still requires 500ms, although there should be 10 per second allowed.In addition, memory from the
ratevariable is never cleaned up. That's not a problem here (because it's a global variable and lives until the program does), but I just wanted to mention it.I done a slight refactoring using the token-bucket rate limiting approach with channels. The bucket is a buffered channel with 10 entries and every request receives a token from it. In another goroutine, the bucket is filled by 10 items every second. If there is no token left, the request blocks until it's filled up again. This solutions handles peaks very well as you can see in the output. A batch of 10 requests is handled the same time and then everything waits for a second.
@davidkroell thank you for your incredibly useful reply.
You're right. My solution may be suitable in some cases, but if the goal is to perform many requests concurrently while maintaining a specific rate limit, then your solution is excellent.