TechPulseTechPulse
Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

60% Positive

Analyzed from 1013 words in the discussion.

Trending Topics

#second#per#requests#unit#hertz#should#rate#write#more#minute

Discussion (22 Comments)Read Original on HackerNews

blackhaz•9 minutes ago
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.
murkt•43 minutes ago
> 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.

childintime•3 minutes ago
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.

blablabla123•12 minutes ago
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

bjoli•about 2 hours ago
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.

bananaflag•about 1 hour ago
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.

bjoli•7 minutes ago
You are right about this. 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.
nofriend•about 1 hour ago
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.
tshaddox•19 minutes ago
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.

nvader•33 minutes ago
So something that is entirely revolving once a second is spinning at 2 * pi Hertz?

Hertz just thinking about it.

smilekzs•31 minutes ago
> 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).

rusk•18 minutes ago
> 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!

pants2•about 1 hour ago
Is a "count" not a valid unit?
orangesilk•41 minutes ago
"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.

hirsin•about 2 hours ago
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.

rswail•27 minutes ago
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.

WaxProlix•about 2 hours ago
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?
spockz•about 2 hours ago
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.

stackghost•about 2 hours ago
>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.

avmich•about 2 hours ago
Can we talk - or assume, or understand - about "average frequencies" of requests and still use Hz as units?
fph•3 minutes ago
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.
ozim•8 minutes ago
No because everyone expects Hz to be as explained in TFA.

It is much more useful as a unit if 4Hz is 250ms event.

curtisf•about 1 hour ago
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