> 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 than 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.
When I see rps in development context, I immediately know it is requests per second. x/s on the other hand… 3x/s. kx/s looks like a physics formula to me. Some spring action? K is for coefficient, x is displacement.
Physicist here: usually bin size is adjusted to change the interval over which you average. Also rpm is the unit if you want to pin it down to a single number
If writing rpm is too long, there's also a trick: write "requests/rpm:"
That means: requests measured in rpm. Thus afterwards you can write single numbers which is even shorter
For me the word becquerel itself requires some additional brain power points to write. Is it bequerel or becquerel? Do we capitalize it or not? Not when written, but Bq is capitalized, so it's indeed kBq. But then again, is it per second? No, the unit, has per second in it already... And we not need to confuse it with B for byte. I thoroughly enjoyed the article but there's no need to complicate the world further. rps is perfectly fine.
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.
You are right about this being confusing. I have thought about whether to adopt in as strict division or whether to be strict about in UNIT to have to produce UNIT. The first one will not resolve the issue of Umits selecting becquerel or Hz to represent N/s, but the second is not as much fun.
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?
The hertz is dimensionally identified as 1/T, and the second is dimensionally identified as T. These are both equally clear, at least dimensionally.
And if anything, the hertz is actually more specified in SI than the second, because the hertz is specifically reserved for describing periodic events, while the second can be used for many things beyond the amount of time between consecutive periodic events.
> 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).
Yeah, that is really something that bothers me from time to time. For instance, in communications we count symbols per second and people still use the unit Hz. But, as it was said before, Hz is revelations per second.
There is a problem in general: Units do not refer to what they count. For instance, when you have dashed road markings and you want to quantify the length of the dashes per road length you get as unit "meters per meters". And then people go and say this is unitless since the units "cancel". But for me, they do not: It stays "dash meter per road meter".
Cycles. I suppose you might say it’s a derivative.
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 angular 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.
Hertz is fixed frequency. Say you poll x times in second with set intervals. It is not measurement of discreet events say packet arriving. Probably best just to leave hertz out unless it is something that is actually fixed rate. So just leave it unitless.
If you define frequency as the derivative of the phase with respect to time, then you also have an instantaneous frequency which (at least formally) also has Hz as unit - even though it does not necessarily describe some real periodicity.
To measure discrete events, I would prefer as unit "events per second" instead of Hz.
As the OP discusses, the current state of the standard formally disallows it: the SI specifies that hertzes are only to be used for periodic phenomena, and becquerels only for radioactivity.
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 than 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.
xps or x/s would be the better unit, no?
Reads like transactions per second. Or as times per second. Or as just anything per second ;)
1100x/s. 1100xps.
When I see rps in development context, I immediately know it is requests per second. x/s on the other hand… 3x/s. kx/s looks like a physics formula to me. Some spring action? K is for coefficient, x is displacement.
Physicist here: usually bin size is adjusted to change the interval over which you average. Also rpm is the unit if you want to pin it down to a single number
If writing rpm is too long, there's also a trick: write "requests/rpm:"
That means: requests measured in rpm. Thus afterwards you can write single numbers which is even shorter
Fun Fact: your salary comes in a very regular Intervall, son you can convert dollars per year to $Hz.
100k$/year is around 3µHz$.
For me the word becquerel itself requires some additional brain power points to write. Is it bequerel or becquerel? Do we capitalize it or not? Not when written, but Bq is capitalized, so it's indeed kBq. But then again, is it per second? No, the unit, has per second in it already... And we not need to confuse it with B for byte. I thoroughly enjoyed the article but there's no need to complicate the world further. rps is perfectly fine.
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.
You are right about this being confusing. I have thought about whether to adopt in as strict division or whether to be strict about in UNIT to have to produce UNIT. The first one will not resolve the issue of Umits selecting becquerel or Hz to represent N/s, but the second is not as much fun.
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?
The hertz is dimensionally identified as 1/T, and the second is dimensionally identified as T. These are both equally clear, at least dimensionally.
And if anything, the hertz is actually more specified in SI than the second, because the hertz is specifically reserved for describing periodic events, while the second can be used for many things beyond the amount of time between consecutive periodic events.
So something that is entirely revolving once a second is spinning at 2 * pi Hertz?
Hertz just thinking about it.
> 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).
Yeah, that is really something that bothers me from time to time. For instance, in communications we count symbols per second and people still use the unit Hz. But, as it was said before, Hz is revelations per second.
There is a problem in general: Units do not refer to what they count. For instance, when you have dashed road markings and you want to quantify the length of the dashes per road length you get as unit "meters per meters". And then people go and say this is unitless since the units "cancel". But for me, they do not: It stays "dash meter per road meter".
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.
> 1 what
Cycles. I suppose you might say it’s a derivative.
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 angular 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.
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.
[delayed]
>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?
Hertz is fixed frequency. Say you poll x times in second with set intervals. It is not measurement of discreet events say packet arriving. Probably best just to leave hertz out unless it is something that is actually fixed rate. So just leave it unitless.
If you define frequency as the derivative of the phase with respect to time, then you also have an instantaneous frequency which (at least formally) also has Hz as unit - even though it does not necessarily describe some real periodicity.
To measure discrete events, I would prefer as unit "events per second" instead of Hz.
As the OP discusses, the current state of the standard formally disallows it: the SI specifies that hertzes are only to be used for periodic phenomena, and becquerels only for radioactivity.
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
No because everyone expects Hz to be as explained in TFA.
It is much more useful as a unit if 4Hz is 250ms event.