SI Units for Request Rate (2024)

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

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

> 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.

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.

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.

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.

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.

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.

"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?