SI Units for Request Rate (2024)

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

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.

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

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.

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.

Can we talk - or assume, or understand - about "average frequencies" of requests and still use Hz as units?