> writing “90 kBq” is a lot more convenient than “ninety thousand requests per second” and “90,000 requests/s”
I once made a joke during the talk that MongoDB is better than Postgres in two ways, and one of those ways is that it’s faster to say “Mongo” than “Post-gres-Qu-eL”.
Same vibe here. 90krps is not that longer 90kBq.
With requests per minute, rpm: engine in my car revs up to 9000 requests per minute!
It’s sometimes funny to see some marketing posts like “we built our infrastructure to handle UNREAL load during the event, 100 million of requests during the day.” Which is just a bit more than 1100 rps.
Hah! I wrote a unit converter for Android recently and that is one of the criticism I get. "Why does my conversion end up in becquerel?" It is usually because people forgot to divide by time, where they write something like "(31l/m2)/1min in mm" when they should have have written something like "(31l/m2)/1min in mm/h". Anyway, check it out here:
I am about 6 days away from publishing and open beta (currently in mandatory closed testing). If you want to join the closed test, you can do so by mailing me at the email at the top of the readme.
I think your interface is a bit inconsistent, this is why people ask that question.
If you have
65mi in 12mi/h -> 19500s
then instead of
12h in s -> 43200s
you should have
12h in s -> 43200
Then a unit at the end should mean that not all dimensions have been reduced.
In the same vein, in the README, the "weird results" section should come after the "dimension removal" section. The way it is now, the apparent "bug" comes before the feature.
The hertz is formally defined as 1/s, except this leaves open the question of 1 what each second. I've seen it argued that since the numerator is unitless, and radians are also unitless, that the hertz as defined refers to one radian per second, and that it should have instead been defined as rev/s. While this argument might be specious, it suggests to us that even if our numerator is unitless, we should still be clear about what kind of thing we are describing rates of. So say "requests per second" if that is what you are talking about, and things will be clearer for everyone.
> that the hertz as defined refers to one radian per second, and that it should have instead been defined as rev/s
This is precisely what leads to the "forgot to multiply 2pi or 1/(2pi)" problem in the EE / signal processing domain where you FFT and s-/fourier-transform back and forth. Heck, I can never remember which convention any particular library / package decides to adopt (esp. mathematica vs. matlab which IIRC caused tons of confusion and headache during my undergrad).
How many times per second the measurement returns to the original value.
In engineering school we used to tie this directly to radians using the Euler notation pow(e, j * 2 * pi * f) where 2pif is your frequency expressed in radians per second!
Is there some obvious reason not to measure requests per minute rather than second? Or is it an offhand joke?
Some systems I've worked on had APIs that averaged less than one per second, but I don't think we want to be measuring in millibecquerels. Some have measured on millions of requests per hour, because the hourly usage was a key quantity, as rate limits were hourly as well.
In my experience, rate limits are more often per second. It's easy to talk about kilo or mega-units, so this isn't as big an issue as the awkwardness of talking about very very low volume services. Maybe those (generally) inherently don't care about rates as much?
In my perception there is a difference between 1req/s as a rate limit, and 60/min. The difference has to do with bucketing. If we agree that the rate limit is 1/s, I expect to be able to exactly that and sometimes 2 within the same second. However, if we agree on 60/min, then it should be fine to spend all 60 in the first second of a minute, or averaged out, or some other distribution.
This also helps with the question I always get when discussing rate limits “but what about bursts?”. 60/min already conveyed you are okay to receive bursts of 60 at once, in contrast to with 1/s.
In my experience it is exactly the low rate service that care about rate limits as they are the most likely to break under higher load. Services that already handle 100k req/s typically don’t sweat it with a couple extra once in a while.
>Is there some obvious reason not to measure requests per minute rather than second?
It's much less obtuse to say something like "average req/min" or whatever, but then again you can't write a cool blog post about misusing an SI unit for radioactivity and shoving it into a nonsensical context.
Sure. A reasonable model for incoming requests within a short window of time is as a "Poisson process", which means the expected number of incoming requests within any interval is proportional to the length of that interval.
The parameter of that distribution is the expected (aka average) rate. If the intervals are time intervals, then the proper units of the parameter are events/second
> writing “90 kBq” is a lot more convenient than “ninety thousand requests per second” and “90,000 requests/s”
I once made a joke during the talk that MongoDB is better than Postgres in two ways, and one of those ways is that it’s faster to say “Mongo” than “Post-gres-Qu-eL”.
Same vibe here. 90krps is not that longer 90kBq.
With requests per minute, rpm: engine in my car revs up to 9000 requests per minute!
It’s sometimes funny to see some marketing posts like “we built our infrastructure to handle UNREAL load during the event, 100 million of requests during the day.” Which is just a bit more than 1100 rps.
Hah! I wrote a unit converter for Android recently and that is one of the criticism I get. "Why does my conversion end up in becquerel?" It is usually because people forgot to divide by time, where they write something like "(31l/m2)/1min in mm" when they should have have written something like "(31l/m2)/1min in mm/h". Anyway, check it out here:
https://github.com/bjoli/Umits
I am about 6 days away from publishing and open beta (currently in mandatory closed testing). If you want to join the closed test, you can do so by mailing me at the email at the top of the readme.
I think your interface is a bit inconsistent, this is why people ask that question.
If you have
65mi in 12mi/h -> 19500s
then instead of
12h in s -> 43200s
you should have
12h in s -> 43200
Then a unit at the end should mean that not all dimensions have been reduced.
In the same vein, in the README, the "weird results" section should come after the "dimension removal" section. The way it is now, the apparent "bug" comes before the feature.
The hertz is formally defined as 1/s, except this leaves open the question of 1 what each second. I've seen it argued that since the numerator is unitless, and radians are also unitless, that the hertz as defined refers to one radian per second, and that it should have instead been defined as rev/s. While this argument might be specious, it suggests to us that even if our numerator is unitless, we should still be clear about what kind of thing we are describing rates of. So say "requests per second" if that is what you are talking about, and things will be clearer for everyone.
Why are you asking “what happened each second” for the SI unit hertz, but not asking “what happened for a second” for the SI unit second?
> that the hertz as defined refers to one radian per second, and that it should have instead been defined as rev/s
This is precisely what leads to the "forgot to multiply 2pi or 1/(2pi)" problem in the EE / signal processing domain where you FFT and s-/fourier-transform back and forth. Heck, I can never remember which convention any particular library / package decides to adopt (esp. mathematica vs. matlab which IIRC caused tons of confusion and headache during my undergrad).
> 1 what
Cycles.
How many times per second the measurement returns to the original value.
In engineering school we used to tie this directly to radians using the Euler notation pow(e, j * 2 * pi * f) where 2pif is your frequency expressed in radians per second!
So something that is entirely revolving once a second is spinning at 2 * pi Hertz?
Hertz just thinking about it.
Is a "count" not a valid unit?
"count" is an incomplete type, the same as "array" is an incomplete type. "count of fruit" would be a complete type, compare to "Array of int64".
SI leaves this underspecified, which causes confusion with dimensionless units.
Is there some obvious reason not to measure requests per minute rather than second? Or is it an offhand joke?
Some systems I've worked on had APIs that averaged less than one per second, but I don't think we want to be measuring in millibecquerels. Some have measured on millions of requests per hour, because the hourly usage was a key quantity, as rate limits were hourly as well.
If you're looking at SI units, the base unit for time is the second.
SI multipliers are all powers of 10, not 60, so minutes and hours are not really compliant.
In my experience, rate limits are more often per second. It's easy to talk about kilo or mega-units, so this isn't as big an issue as the awkwardness of talking about very very low volume services. Maybe those (generally) inherently don't care about rates as much?
In my perception there is a difference between 1req/s as a rate limit, and 60/min. The difference has to do with bucketing. If we agree that the rate limit is 1/s, I expect to be able to exactly that and sometimes 2 within the same second. However, if we agree on 60/min, then it should be fine to spend all 60 in the first second of a minute, or averaged out, or some other distribution.
This also helps with the question I always get when discussing rate limits “but what about bursts?”. 60/min already conveyed you are okay to receive bursts of 60 at once, in contrast to with 1/s.
In my experience it is exactly the low rate service that care about rate limits as they are the most likely to break under higher load. Services that already handle 100k req/s typically don’t sweat it with a couple extra once in a while.
>Is there some obvious reason not to measure requests per minute rather than second?
It's much less obtuse to say something like "average req/min" or whatever, but then again you can't write a cool blog post about misusing an SI unit for radioactivity and shoving it into a nonsensical context.
Can we talk - or assume, or understand - about "average frequencies" of requests and still use Hz as units?
Sure. A reasonable model for incoming requests within a short window of time is as a "Poisson process", which means the expected number of incoming requests within any interval is proportional to the length of that interval.
The parameter of that distribution is the expected (aka average) rate. If the intervals are time intervals, then the proper units of the parameter are events/second