> 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.
Mostly, people who do “requests per day” have a lot lower load than 1100 requests/sec, too… it's a typical red flag for having a team that know a lot less about performance than they think.
Frankly, that usually comes from orgs that deal with the real world. 50k generic requests per day is nothing. 50k orders per day for a small e-commerce company can be pretty overwhelming.
It’s becoming laughable when people use it to boast about microservices or something :)
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.
I like using units that are already used to describe what is meant, e.g. if you have a periodic frequency Hz is totally fine and easy to math with. Now I wasn't aware of Bq, but it makes sense to have a separate unit for the stochastic equivalent.
The only problem with that unit is that it may require explaination. Hertz is a little bit more commonly understood, while someone seeing 2.5 Bq will very likely wonder what that means.
In the end both Hz and Bq resolve to s⁻¹ or 1/s So maybe request/s is just okay as a unit? In the end it depends also on the surrounding UI.
The authority on the definition of SI units is very clear:
> The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic
processes in activity referred to a radionuclide
Clearly, we should place a radioactive source, a Geiger counter, and a computer in a sealed box. Every time the counter registers a decay, the computer performs a HTTP GET. Thus, we end up with Schrödinger's webserver...
I think this is mostly to blame on Grafana. Every dashboard ships with $__interval by default and every query uses that by default. I never understood the value of that. It makes the graphs look pretty I guess, but looking at the values becomes a little less useful because nothing is compareable to another not even to yesterday when you last looked at the dashboard.
Personally I always setup a variable $interval that can be set to 1m, 5m, 15m etc and use that in all my queries.
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.
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
Has anyone ever run Fourier analysis on their request rate and found something interesting? Bonus points if it's not a day/night or weekday/weekend thing.
I actually did that recently, but only at low sample rate so I don't qualify for bonus points. (My purpose was filtering to get at underlying patterns. Found what I expected but not much more.)
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.
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.
The hertz is not dimensionally identified as 1/T, despite the fact that this has been voted in 1995 by the clueless delegates to the CGPM.
The hertz is a name for cycle per second and the physical quantity that is measured in hertz is plane angle per time a.k.a. phase angle per time, not reciprocal time.
> 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).
The modern SI contains several serious mistakes, and the fact that they are the result of votes demonstrates that democracy is inapplicable in sciences like mathematics and physics, because the majority of the people are incompetent enough to vote things equivalent with saying that "2 + 2 = 5", but regardless if such things are voted by a majority of humans, they remain false.
The hertz is not "1/s" and everyone who has been brainwashed by school education to believe this misses some of the most important concepts on which physics is based.
Originally, "hertz" has been defined as a name for "cycle/s", not for "1/s", and that is the correct definition, which has always been the one used in practice, regardless of what is written in the SI brochure.
"cycle" is a unit for plane angle a.k.a. phase angle, so "hertz" is the SI unit for the physical quantity "angle/time", not for the quantity "reciprocal time". SI is an inconsistent system of units, because it uses 2 units for plane angles: cycles and radians. In practice, the right choice is to always measure angle in cycles, not in radians, because using cycles ensures both a higher accuracy in computations and faster computations (because the argument range reductions in trigonometric functions become exact and fast) and because all high-precision sensors and actuators must use cycles not radians, so when radians are used in computations that requires additional conversions.
The current wrong definition of the hertz is a consequence of an outrageous and shameful resolution voted in 1995: "Resolution 8 of the 20th CGPM", where it was voted that the units of plane angle and solid angle are not base units a.k.a. fundamental units, so these quantities should not be used in dimensional formulae.
This resolution is just an example of human stupidity. You cannot establish by vote whether a unit of measurement is fundamental or derived. Any unit of measurement that cannot be derived from other units is a base unit a.k.a. fundamental unit.
There are 3 fundamental units that are missing from SI (the units of logarithms, plane angles and solid angles), despite the fact that their use is extremely frequent in practice, and one of them, the unit of plane angle, is actually the most important fundamental unit, because for the highest precision in measurements all other continuous physical quantities are eventually converted into phase angles before the analog-to-digital conversion (because when phase angles are measured in cycles, the measurement can be reduced to counting, i.e. to cycle counting).
In theory, one could choose as fundamental only one of the 3 units of logarithms, plane angles and solid angles, and derive the others from it. The unit of solid angle can be derived from the unit of plane angle by setting to "1" the proportionality factor in Albert Girard’s theorem (by using this method, the steradian is derived from the radian, the hemisphere is derived from the cycle and the solid angle degree is derived from the sexagesimal degree, where a full sphere has 720 solid angle degrees; during the first 2 centuries after the beginning of the 17th cetury, when it was defined how to measure solid angles, the solid angle degree was the main unit of measurement). The unit of logarithms can be derived from the unit of plane angle by setting to "1" the ratio between the proportionality factors that appear in the formulae for the derivatives of exponential and trigonometric functions.
Choosing only 1 of these 3 units as base unit and deriving the other 2 from it results in the 3 units neper, radian and steradian. However, neper and radian are very inconvenient units, so in practice it is far better to choose independently the units of logarithms, plane angles and solid angles.
Regardless whether one chooses independent units for logarithms and solid angles, or they are derived from the unit of plane angle, it is impossible to derive the unit of plane angle from the currently official units of SI.
Some publications claim that the plane angle unit can be derived from the unit of length, supposedly because the measure of an angle is the ratio between the length of a corresponding arc and the radius of the circle.
This pseudo-argument demonstrates a complete lack of understanding of how physical quantities are measured. There are 2 variants of this pseudo-argument, which contradict each other and both are equally false. First, saying that this shows that the unit of angle is derived from the unit of length is obviously false. The reason is that when you divide two lengths, the unit of length is divided by itself, so the result of the division is independent of the unit of length, therefore this formula cannot derive anything from the unit of length.
The second formulation of the pseudo-argument is that this formula shows that the plane angle is an "adimensional quantity" a.k.a. "dimensionless quantity". This claim is equally ridiculous. As understood very well more than a century and a half ago (e.g. the theory of measurements was explained more clearly by James Clerk Maxwell than by most modern handbooks of physics), the measurement of any physical quantity is expressed by the product of 2 factors, a unit of measurement and a dimensionless numeric value.
The ratio between the length of an arc and the radius is not the complete value of a plane angle. It is just the dimensionless numeric value of an angle, in the special case when the angle is measured in radians. To obtain the complete angle value you must multiply that ratio by 1 radian. The "radius" in that formula is not truly the radius, but it is the length of the arc corresponding to the unit angle. When angles are measured in cycles, the length of a unit angle is the perimeter, so the dimensionless numeric value of an angle is equal to the ratio between the length of the arc and the perimeter.
Applying the pseudo-argument that plane angle is dimensionless to length "proves" that length is dimensionless, because the length of any object is obtained by dividing its length by the length of an 1 m ruler. Similarly for any other physical quantity.
The fact that the unit of plane angle is fundamental is demonstrated beyond any reasonable doubt by the fact that you can choose any angle unit you want, and many such units are really used in practice, e.g. cycle, radian, sexagesimal degree, centesimal degree, right angle, etc., and for each choice of a unit of plane angle you obtain a different system of units for the physical quantities. Between the numeric values measured in the different system of units there are conversion formulae that are constructed exactly in the same way as when changing for example the unit of length from meter to inch.
In order to be able to generate automatically the conversion formulae when the unit of plane angle is changed, you need to have the plane angle in the dimensional formulae of the physical quantities. The fact that most physics books usually omit the plane angle from dimensional formulae is a source of mistakes, especially when comparing some modern numeric values with values from old publications, where non-SI systems of units were used, which sometimes were based on implicit assumptions that were different from the implicit assumptions used by SI.
In SI, implicit assumptions are made everywhere. In most cases it is assumed that angles are measured in radians, and when other angle units are used the displayed formulae become wrong, despite the fact that it is claimed that they are written in a form that does not depend on which units are used. Nevertheless, wherever "hertz" is involved, it is implicitly assumed that plane angles are measured in cycles, not in radians.
The term "frequency" has 2 meanings in physics. Originally, "frequency" was the name for the ratio between the number of some random events that occur during some time interval and the duration of that time interval.
At earlier authors, before the last years of the 19th century, "frequency" was used only with this meaning. It was never used for periodic phenomena. Periodic phenomena were described using period and wave-length.
Some time around 1890, "frequency" began to be used with a second meaning, as the ratio between the number of cycles of a periodic phenomena and the duration of a time interval. After that time it has become more common to describe periodic phenomena using frequency and wave-number (i.e. number of waves), instead of using period and wave-length.
The two kinds of frequencies are distinct physical quantities, with distinct units of measurement. Frequency with the second meaning is the ratio between plane angle and time. Possible units are radian per second and cycle per second, where the latter is named hertz. Frequency with the first meaning is the ratio between a number of events (which is a discrete quantity, not a continuous quantity, like for the other kind of frequency) and time. SI has the name becquerel for this unit of measurement.
The author of the parent article is perfectly right that the becquerel is the appropriate unit of measurement for the frequency a.k.a. rate of any random events.
When you see "frequency" in a physics text, you must always pay attention to recognize which of its 2 meanings is used. Similarly, "phase" has 2 meanings, which must be distinguished. Originally, "phase" was the fractional part of a rotation angle measured in cycles. This meaning was more useful, but later "phase" began to be used for the integral of frequency with the second meaning, i.e. for the total rotation angle, not only for its fractional part.
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.
An effective rate limiting system has multiple bases in my experience, depending on what the goal is. But I usually implement the configuration as a list where you can define how much requests are allow maximum per how many units of time.
E.g. to prevent fast bursts you limit it to 1 request per 1 second, but to avoid someone sending out 86400 requests a day you also cap them at 100 per 86400 seconds (24 hours) and 1000 per 3600 seconds (1 hour).
Whichever limit they hit first will stop it. That isn't hard to implement if you know how to deal with arrays and it allows long term abuse, while still along fast retries if something went wrong.
I guess there's a difference between talking about how many requests a system is capable of handling, and how many they actually get.
At least when i encountered the discussion initially (some thirty years ago) I'd say we usually talked about how many requests the system was capable of handling. Then requests per second was the obvious unit since a request usually took less than a second to process (obviously depending on the system and so on - but mostly), so using that unit often gave a fairly low, comprehensible number.
Was it ten? A hundred (very impressive)? Perhaps even a thousand (very, very impressive!)?
Multiply those numbers by 60, and there's suddenly a lot more mental gymnastics involved. By 3600 and you're well into "all big numbers look the same" land.
>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.
"writing “90 kBq” is a lot more convenient than “ninety thousand requests per second” and “90,000 requests/s”"
Not sure if article is serious or tongue-in-cheek, but no this isn't more convenient because it is more difficult to understand.
"requests/s" is best because it is the clearest, most unambiguous, and easiest to understand instantly. SI factors can be used on the number if needed (90k instead of 90,000)
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
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.
Well the SI unit for request rate is … requests/s. Just like speed is m/s and not something bespoke.
However when the infra is crumbling under requests (one could say decaying), then becquerel seems appropriate
For it to be an SI unit, shouldn't you be able to express it in terms of the 7 SI base units?
And what if something goes from rest to light speed every second to average 1 m/s over the second. Is that the same thing as smooth 1 m/s?
> 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.
Mostly, people who do “requests per day” have a lot lower load than 1100 requests/sec, too… it's a typical red flag for having a team that know a lot less about performance than they think.
Frankly, that usually comes from orgs that deal with the real world. 50k generic requests per day is nothing. 50k orders per day for a small e-commerce company can be pretty overwhelming.
It’s becoming laughable when people use it to boast about microservices or something :)
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.
I like using units that are already used to describe what is meant, e.g. if you have a periodic frequency Hz is totally fine and easy to math with. Now I wasn't aware of Bq, but it makes sense to have a separate unit for the stochastic equivalent.
The only problem with that unit is that it may require explaination. Hertz is a little bit more commonly understood, while someone seeing 2.5 Bq will very likely wonder what that means.
In the end both Hz and Bq resolve to s⁻¹ or 1/s So maybe request/s is just okay as a unit? In the end it depends also on the surrounding UI.
I really had a hard time figuring out if the post is satire.
Mackerels per second would be funnier though, if were making shit up.
Please don't.
The authority on the definition of SI units is very clear:
> The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic processes in activity referred to a radionuclide
Neither is usually the case for requests.
https://www.bipm.org/documents/d/guest/si-brochure-9-en-pdf
Clearly, we should place a radioactive source, a Geiger counter, and a computer in a sealed box. Every time the counter registers a decay, the computer performs a HTTP GET. Thus, we end up with Schrödinger's webserver...
I think this is mostly to blame on Grafana. Every dashboard ships with $__interval by default and every query uses that by default. I never understood the value of that. It makes the graphs look pretty I guess, but looking at the values becomes a little less useful because nothing is compareable to another not even to yesterday when you last looked at the dashboard.
Personally I always setup a variable $interval that can be set to 1m, 5m, 15m etc and use that in all my queries.
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.
I think the behaviour is good as it is, it is just the output display that should be consistent (as I suggested in my example).
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
Has anyone ever run Fourier analysis on their request rate and found something interesting? Bonus points if it's not a day/night or weekday/weekend thing.
I actually did that recently, but only at low sample rate so I don't qualify for bonus points. (My purpose was filtering to get at underlying patterns. Found what I expected but not much more.)
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$.
That sounds too low; 3 m$Hz would probably be right, but 3 µ$Hz is very little.
Yes, the year has pi * 1e7 seconds
1e5 / 3.14e7 ≈ 3e-3, milli, not micro
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.
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.
The hertz is not dimensionally identified as 1/T, despite the fact that this has been voted in 1995 by the clueless delegates to the CGPM.
The hertz is a name for cycle per second and the physical quantity that is measured in hertz is plane angle per time a.k.a. phase angle per time, not reciprocal time.
According to your proposal, phase angle must not be dimensionless, right?
So something that is entirely revolving once a second is spinning at 2 * pi Hertz?
Hertz just thinking about it.
https://en.wikipedia.org/wiki/Angular_frequency
It's very convenient when you're working with periodic signals (say, when discussing the FFT); you don't have to drag a 2pi factor around everywhere.
> 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).
The modern SI contains several serious mistakes, and the fact that they are the result of votes demonstrates that democracy is inapplicable in sciences like mathematics and physics, because the majority of the people are incompetent enough to vote things equivalent with saying that "2 + 2 = 5", but regardless if such things are voted by a majority of humans, they remain false.
The hertz is not "1/s" and everyone who has been brainwashed by school education to believe this misses some of the most important concepts on which physics is based.
Originally, "hertz" has been defined as a name for "cycle/s", not for "1/s", and that is the correct definition, which has always been the one used in practice, regardless of what is written in the SI brochure.
"cycle" is a unit for plane angle a.k.a. phase angle, so "hertz" is the SI unit for the physical quantity "angle/time", not for the quantity "reciprocal time". SI is an inconsistent system of units, because it uses 2 units for plane angles: cycles and radians. In practice, the right choice is to always measure angle in cycles, not in radians, because using cycles ensures both a higher accuracy in computations and faster computations (because the argument range reductions in trigonometric functions become exact and fast) and because all high-precision sensors and actuators must use cycles not radians, so when radians are used in computations that requires additional conversions.
The current wrong definition of the hertz is a consequence of an outrageous and shameful resolution voted in 1995: "Resolution 8 of the 20th CGPM", where it was voted that the units of plane angle and solid angle are not base units a.k.a. fundamental units, so these quantities should not be used in dimensional formulae.
This resolution is just an example of human stupidity. You cannot establish by vote whether a unit of measurement is fundamental or derived. Any unit of measurement that cannot be derived from other units is a base unit a.k.a. fundamental unit.
There are 3 fundamental units that are missing from SI (the units of logarithms, plane angles and solid angles), despite the fact that their use is extremely frequent in practice, and one of them, the unit of plane angle, is actually the most important fundamental unit, because for the highest precision in measurements all other continuous physical quantities are eventually converted into phase angles before the analog-to-digital conversion (because when phase angles are measured in cycles, the measurement can be reduced to counting, i.e. to cycle counting).
In theory, one could choose as fundamental only one of the 3 units of logarithms, plane angles and solid angles, and derive the others from it. The unit of solid angle can be derived from the unit of plane angle by setting to "1" the proportionality factor in Albert Girard’s theorem (by using this method, the steradian is derived from the radian, the hemisphere is derived from the cycle and the solid angle degree is derived from the sexagesimal degree, where a full sphere has 720 solid angle degrees; during the first 2 centuries after the beginning of the 17th cetury, when it was defined how to measure solid angles, the solid angle degree was the main unit of measurement). The unit of logarithms can be derived from the unit of plane angle by setting to "1" the ratio between the proportionality factors that appear in the formulae for the derivatives of exponential and trigonometric functions.
Choosing only 1 of these 3 units as base unit and deriving the other 2 from it results in the 3 units neper, radian and steradian. However, neper and radian are very inconvenient units, so in practice it is far better to choose independently the units of logarithms, plane angles and solid angles.
Regardless whether one chooses independent units for logarithms and solid angles, or they are derived from the unit of plane angle, it is impossible to derive the unit of plane angle from the currently official units of SI.
Some publications claim that the plane angle unit can be derived from the unit of length, supposedly because the measure of an angle is the ratio between the length of a corresponding arc and the radius of the circle.
This pseudo-argument demonstrates a complete lack of understanding of how physical quantities are measured. There are 2 variants of this pseudo-argument, which contradict each other and both are equally false. First, saying that this shows that the unit of angle is derived from the unit of length is obviously false. The reason is that when you divide two lengths, the unit of length is divided by itself, so the result of the division is independent of the unit of length, therefore this formula cannot derive anything from the unit of length.
The second formulation of the pseudo-argument is that this formula shows that the plane angle is an "adimensional quantity" a.k.a. "dimensionless quantity". This claim is equally ridiculous. As understood very well more than a century and a half ago (e.g. the theory of measurements was explained more clearly by James Clerk Maxwell than by most modern handbooks of physics), the measurement of any physical quantity is expressed by the product of 2 factors, a unit of measurement and a dimensionless numeric value.
The ratio between the length of an arc and the radius is not the complete value of a plane angle. It is just the dimensionless numeric value of an angle, in the special case when the angle is measured in radians. To obtain the complete angle value you must multiply that ratio by 1 radian. The "radius" in that formula is not truly the radius, but it is the length of the arc corresponding to the unit angle. When angles are measured in cycles, the length of a unit angle is the perimeter, so the dimensionless numeric value of an angle is equal to the ratio between the length of the arc and the perimeter.
Applying the pseudo-argument that plane angle is dimensionless to length "proves" that length is dimensionless, because the length of any object is obtained by dividing its length by the length of an 1 m ruler. Similarly for any other physical quantity.
The fact that the unit of plane angle is fundamental is demonstrated beyond any reasonable doubt by the fact that you can choose any angle unit you want, and many such units are really used in practice, e.g. cycle, radian, sexagesimal degree, centesimal degree, right angle, etc., and for each choice of a unit of plane angle you obtain a different system of units for the physical quantities. Between the numeric values measured in the different system of units there are conversion formulae that are constructed exactly in the same way as when changing for example the unit of length from meter to inch.
In order to be able to generate automatically the conversion formulae when the unit of plane angle is changed, you need to have the plane angle in the dimensional formulae of the physical quantities. The fact that most physics books usually omit the plane angle from dimensional formulae is a source of mistakes, especially when comparing some modern numeric values with values from old publications, where non-SI systems of units were used, which sometimes were based on implicit assumptions that were different from the implicit assumptions used by SI.
In SI, implicit assumptions are made everywhere. In most cases it is assumed that angles are measured in radians, and when other angle units are used the displayed formulae become wrong, despite the fact that it is claimed that they are written in a form that does not depend on which units are used. Nevertheless, wherever "hertz" is involved, it is implicitly assumed that plane angles are measured in cycles, not in radians.
The term "frequency" has 2 meanings in physics. Originally, "frequency" was the name for the ratio between the number of some random events that occur during some time interval and the duration of that time interval.
At earlier authors, before the last years of the 19th century, "frequency" was used only with this meaning. It was never used for periodic phenomena. Periodic phenomena were described using period and wave-length.
Some time around 1890, "frequency" began to be used with a second meaning, as the ratio between the number of cycles of a periodic phenomena and the duration of a time interval. After that time it has become more common to describe periodic phenomena using frequency and wave-number (i.e. number of waves), instead of using period and wave-length.
The two kinds of frequencies are distinct physical quantities, with distinct units of measurement. Frequency with the second meaning is the ratio between plane angle and time. Possible units are radian per second and cycle per second, where the latter is named hertz. Frequency with the first meaning is the ratio between a number of events (which is a discrete quantity, not a continuous quantity, like for the other kind of frequency) and time. SI has the name becquerel for this unit of measurement.
The author of the parent article is perfectly right that the becquerel is the appropriate unit of measurement for the frequency a.k.a. rate of any random events.
When you see "frequency" in a physics text, you must always pay attention to recognize which of its 2 meanings is used. Similarly, "phase" has 2 meanings, which must be distinguished. Originally, "phase" was the fractional part of a rotation angle measured in cycles. This meaning was more useful, but later "phase" began to be used for the integral of frequency with the second meaning, i.e. for the total rotation angle, not only for its fractional part.
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.
An effective rate limiting system has multiple bases in my experience, depending on what the goal is. But I usually implement the configuration as a list where you can define how much requests are allow maximum per how many units of time.
E.g. to prevent fast bursts you limit it to 1 request per 1 second, but to avoid someone sending out 86400 requests a day you also cap them at 100 per 86400 seconds (24 hours) and 1000 per 3600 seconds (1 hour).
Whichever limit they hit first will stop it. That isn't hard to implement if you know how to deal with arrays and it allows long term abuse, while still along fast retries if something went wrong.
I guess there's a difference between talking about how many requests a system is capable of handling, and how many they actually get.
At least when i encountered the discussion initially (some thirty years ago) I'd say we usually talked about how many requests the system was capable of handling. Then requests per second was the obvious unit since a request usually took less than a second to process (obviously depending on the system and so on - but mostly), so using that unit often gave a fairly low, comprehensible number.
Was it ten? A hundred (very impressive)? Perhaps even a thousand (very, very impressive!)?
Multiply those numbers by 60, and there's suddenly a lot more mental gymnastics involved. By 3600 and you're well into "all big numbers look the same" land.
>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.
"writing “90 kBq” is a lot more convenient than “ninety thousand requests per second” and “90,000 requests/s”"
Not sure if article is serious or tongue-in-cheek, but no this isn't more convenient because it is more difficult to understand.
"requests/s" is best because it is the clearest, most unambiguous, and easiest to understand instantly. SI factors can be used on the number if needed (90k instead of 90,000)
Can we talk - or assume, or understand - about "average frequencies" of requests and still use Hz as units?
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
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.
No because everyone expects Hz to be as explained in TFA.
It is much more useful as a unit if 4Hz is 250ms event.