Understanding rate/throttle pool in `req_throttle`

[jchrom]

I may just be doing something silly, but these timings look off to me. I am using the CRAN version on Ubuntu 20.04 and R 4.1.2.

library(dplyr)
library(httr2)

get_throttled <- function(url, rate) {
  message(Sys.time())
  request(url) %>%
    req_throttle(rate) %>%
    req_method("get") %>% 
    req_perform()
}

urls <- rep("https://httpbin.org/status/200", 60)

system.time(x <- lapply(urls, get_throttled, rate = 1))

#  user  system elapsed 
# 0.666   0.125  34.302

system.time(x <- lapply(urls, get_throttled, rate = 30/60))

#  user  system elapsed 
# 0.826   0.199  64.362

system.time(x <- lapply(urls, get_throttled, rate = 10/60))

#  user  system elapsed 
# 1.344   0.646 183.221

[hadley]

What seems off to you? 60 = 2 * 30 and 180 = 6 * 30.

...

Oh the ratios are ok, but if you download one url per second, you'd expect it to take 60s to download 60 urls.

[jchrom]

Yes, it is consistently taking about half the time I would expect it to take. The "overhead" seems similar as well, 3-4 seconds.

[jchrom]

I looked into req_throttle() and came up with a simple, if a bit inelegant fix. I will prepare a pull request. In the meantime, here are my thoughts:

It is useful to think about what last in last <- the$throttle[[realm]] actually means. It seems logical that it should mean "the time last request was issued". If the expected delay is 10s and the last request was issued 7s ago, that makes 10 - 7 = 3s to wait.

But currently, last does not mean that. Instead, it means "the time the last waiting period started" because the new value of last is set before the sys_sleep() call in req_perform().

Essentially, we are pretending the last request happened earlier than it really happened. Each waiting period is therefore subtracted from the next. The total time is halved as a result.