by tuetuopay
2 subcomments
- 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
- > 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.
- 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
by DaveFlater
0 subcomment
- SI avoids identifying countable entities and events except in special cases like bequerel. This is but one example among many where the needs of IT are outside the scope that SI serves.
https://www.researchgate.net/publication/339954122_Quantitie...
- 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.
by blablabla123
0 subcomment
- 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.
by cyberrock
1 subcomments
- 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.
by throw_await
1 subcomments
- 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$.
- 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.
- Related. Others?
SI Units for Request Rate - https://news.ycombinator.com/item?id=39219573 - Feb 2024 (93 comments)
- 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.
- The problem with becquerel is that it makes me think of bechamel which makes me think of lasagna. Now I have to remove drool from the keyboard. Thanks for nothing, OP!
- Thanks, I'm converted.
I also think that there are other silly units:
mAh -> C
kWh -> J
kg -> gv
by mytailorisrich
0 subcomment
- "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?
Hacker News