SI Units for Request Rate

https://two-wrongs.com/si-units-for-request-rate

by DaveFlater • 2 years ago

111 91 2 years ago

DaveFlater4• 2 years ago

The "two wrongs" hostname is apt. Hertz is for periodic phenomena; becquerel is for radioactive decay. The SI brochure discourages the use of counting units such as 'request'. The number of requests is regarded as just a number, or at best a quantity that is referred to the unit one. The applicable SI unit therefore is just the reciprocal second, s^(-1).

In practice, counting units are used everywhere (e.g., in MB/s, the byte is a counting unit), but I am relaying what the SI brochure actually says on this question.

Ref: https://www.bipm.org/en/publications/si-brochure/

basil-rash5• 2 years ago

No way the same org that named the mole a unit discourages the use of counting units.

I think what we are really after is yoctomole Becquerels.

krastanov• 2 years ago

Interestingly, a "conservation of matter" law can exist independently of atoms. I.e. it is mathematically consistent to create a universe in which a "mole" is necessary, but matter is not discrete. Therefore "mole" can be considered a bit more fundamental (in any universe). I find it reasonable to stick to using a "mole" unit on that basis, although I would not be dying on this hill.

roland_nilsson2• 2 years ago

The yoctomole is a wonderful unit, for example when you want just slightly more than half a cup of coffee!

But the mole as a "counting unit" is different from OP's idea of assigning units to things like network requests. The mole is just a shorthand for a number, like a dozen or a score. We don't have different kind of "moles" for, say, carbon atoms and water molecules. Or coffee.

jameshart8• 2 years ago

It can, in my experience, be very useful to introduce a unit for ‘requests’, as well as one for ‘CPUs’.

It lets us produce dimensionally valid formulae for relating request rates (in requests per second) to compute requirements (in CPU seconds per request), data transfer (in bytes per request), and bandwidth (in bytes per second).

I kind of wish software engineering’s computer science underpinnings offered a few more of the kind of notational underpinnings that physics offers mechanical or electronic engineers.

Why don’t we have a standard set of letters for representing data sizes, requests, compute units, etc; and a set of widely known formulae as familiar to every programmer as V=IR is to an electrical engineer?

The only standard symbol computer science has given us (or maybe more accurately that we have taken up) is n, as in O(n), for collection sizes.

I wonder if we can do better?

DaveFlater4• 2 years ago

ISO 80000 Part 13 gives some symbols within the scope of communication technology (its scope is more narrow than its title would suggest). The standard itself is copyrighted but the quantity symbols are listed on Wikipedia, https://en.wikipedia.org/wiki/ISO/IEC_80000#Part_13:_Informa...

boolemancer• 2 years ago

Personally I like variable names better than symbols anyway.

asveikau• 2 years ago

A cpu second means very little without more context. CPU performance depends a lot on things like cache, branch prediction, out of order execution. Each second represents something fairly distinct from the others.

nyrikki4• 2 years ago

In reference to (per duration) values "requests per second" is ambiguous, what is a request?

Instructions per seconds exists but is only useful for comparing tasks on the same hardware and architecture. We saw the abuse of MIPS for comparing machines in the past just as we see it with FLOPS in GPUs today.

MIPS benchmarks like whetstone differ even on the same CPU depend on the language used, compiler used, and the options at compile time. TPC, SPEC and other synthetic benchmarks just succumbed to game theory and usually don't apply to real world loads.

The field you want to look into is "Queuing Theory"

If you are lucky enough that you can assume your system is Markovian you get simple formula like:

mean service time == 1/(mean service rate)

To show just how old it is here is a good paper about M/M/1 queues from 1958 that is still useful today.

https://msp.org/pjm/1958/8-1/pjm-v8-n1-p08-s.pdf

rerdavies4• 2 years ago

relating request rates (in requests per second) to compute requirements (in CPU seconds per request)

The exist SI unit which specifically applies to queueing problems is the erlang, a unit originally used in telecommunications. Applied to computers, it would translate to CPU use per request.

https://en.wikipedia.org/wiki/Erlang_(unit)

It's considered to be a dimensionless unit (according to wiki), implying that CPUs and requests are also dimensionless.

thaumasiotes3• 2 years ago

Hertz is for periodic phenomena
The applicable SI unit therefore is just the reciprocal second, s^(-1).

That's the hertz.

petschge• 2 years ago

While Hertz are 1/s, there is implications between using frequencies in Hertz and rates in 1/s. Units are not just something to mechanically check, but also for communication with other humans. So connotations matter in addition to denotation.

DaveFlater4• 2 years ago

Hertz, becquerel, et al. are algebraically defined as s^(-1) yet intended to be used for different kinds of quantities. The SI brochure also allows replacing radian by 1, which brings angular velocity into the fight. Further reading: https://doi.org/10.1088/0026-1394/52/1/40

OskarS• 2 years ago

Would you say that one watt is equal to one joule-hertz?

Terr_• 2 years ago

Are you suggesting it is sensible to measure airplane crashes in hertz?

It's not algebraically incorrect, but it contains something dangerously wrong connotations about what kind of data it is.

https://xkcd.com/687/

mytailorisrich3• 2 years ago

Not necessarily. As mentioned by others the Hertz is for frequencies of periodic phenomena. While its dimension is indeed s^-1, that says nothing about periodicity.

The Becquerel is also s^-1.

charles_f2• 2 years ago

Hertz is the SI unit of frequency.

msylvest• 2 years ago

Within the area of viscosities reciprocal seconds is an accepted standard unit

paulsutter• 2 years ago

If becquerel why not microfortnight? (about a second)

amluto• 2 years ago

That’s not the same thing at all. You obviously mean the inverse microfortnight.

basil-rash5• 2 years ago

And the problem with that of course is whether the µfn is 1,000/(2 weeks) or 1/(2,000 weeks).

All in all the Bq is a cool unit! I learned something today.

afc• 2 years ago

Because the point is to have a Si unit of event rate (becquerel), not of time. Otherwise, if micro-fortnight (about a second), why not ... second?

ursusmaritimus• 2 years ago

Maybe we can generalize the becquerel to mean the average number of events per second of an arbitrary Poisson process? (The number requests per second and the number of decayed particles per second usually follow Poisson distribution.)

diarrhea• 2 years ago

I don’t understand what’s wrong with Hz. Bq is almost viciously misguided.

basil-rash5• 2 years ago

By the books, Hz is only for regular phenomena. To the extent human activity is a magnifying lens of underlying quantum activity, as is radioactive activity, Bq are better suited.

It is indeed the unit of “activity”, not rate.

mytailorisrich3• 2 years ago

Hz is for frequency, which is for periodic phenomena (1/period equals frequency).

Usually requests to a server are not periodic, there is no period. They are random and follow something like the Poisson distribution.

Requests per seconds is as SI as it gets since the second is the base SI unit for time.

maxnoe• 2 years ago

They are random and follow something like the Poisson distribution.

In "stable conditions":

* The number of requests in a given time interval will follow a poisson distribution.

* The times of requests will be uniformly distributed

* the duration between two consecutive requests will be exponentially distributed.

bmacho• 2 years ago

The becquerel, or Bq, is the si unit of (radio)activity. It is also defined as one event per second.

Bq is not defined as "one event per second". One becquerel is defined "as the activity of a quantity of radioactive material in which one nucleus decays per second." https://en.wikipedia.org/wiki/Becquerel

AnotherGoodName• 2 years ago

Well si doesn't really care about distributions. So it's a gamma distribution with an average rate in hz. Don't bother looking for the distribution in the units.

IshKebab• 2 years ago

This is stupid. The unit is "requests/s".

jprival• 2 years ago

“rips” -> “kilorips” etc.

jonathaneunice• 2 years ago

Nice repurposing. Bq it is!

prpl• 2 years ago

Counts per second doesn’t need a unit. It’s probably closer to flux (generic definition, not specific definition).

counts per second is common in particle physics

jameshart8• 2 years ago

Flux is a quantity of ‘something’ per unit time per unit ‘area’.

The value of flux measurements is to be comparable across different scales.

When looking at scaling software systems the equivalent is looking at ‘requests per second per process’, which is sort of a flux metric. One way to think of auto scaling is as a process that adjusts the number of processes to keep constant request flux as the overall request volume changes.

kqr2• 2 years ago

I like this line of thinking! We should be able to set up differential equations that express how traffic flows through the process network and solve performance like a fluid dynamics problem!

rollcat• 2 years ago

I propose that we shall use bananas as the unit for request rate (one banana = one request per second); it's obviously appropriate as:

1. Bananas are the de-facto standard for measuring the relative size of things posted online. Request rate is a relative quantity, since requests can have varying payload sizes, transfer rates, or server-side resource usage, even within the context of a single service (unlike decay rate, which to my understanding is usually considered within the context of a uniform sample of radioactive material).

2. The web has been steadily turning more toxic over the past several decades; you could call it a form of decay, but all radioactive decay eventually produces stable elements; no such trend has been observed with the web.

3. While bananas can trip up radiation detectors, they are much more likely to just go bad - same with web requests on your server; if you can't process them in a timely manner, better just throw them away.

jbandela1• 2 years ago

I think 1 banana should be 16 requests per second.

This is because a banana has around 12 - 18 Becquerels of radiation. 16 is a nice power of 2 number.

trklausss2• 2 years ago

Americans will use any unit of measure but SI units… /s

erik_seaberg• 2 years ago

Bananas are a measure of complexity dating back to the Jargon File. E.g., you could easily persuade a trained monkey to fix a one-banana problem.

mci• 2 years ago

How about a third unit, baud [1]? It looks no worse than hertz to me:

In telecommunication and electronics, baud (/bɔːd/; symbol: Bd) is a common unit of measurement of symbol rate, which is one of the components that determine the speed of communication over a data channel. It is the unit for symbol rate or modulation rate in symbols per second or pulses per second.

[1] https://en.wikipedia.org/wiki/Baud

mytailorisrich3• 2 years ago

Baud is indeed symbols per second.

For a server, requests per seconds is the best SI unit you can do. In practice requests to a server are random so there is no periodicity and all periodic/frequency-related units do not apply.

zokier• 2 years ago

Wikipedia has short section for this

Aperiodic frequency is the rate of incidence or occurrence of non-cyclic phenomena, including random processes such as radioactive decay. It is expressed with the unit of reciprocal second (s⁻¹)[14] or, in the case of radioactivity, becquerels.[15]
It is defined as a rate, f = N/Δt, involving the number of entities counted or the number of events happened (N) during a given time duration (Δt);[citation needed] it is a physical quantity of type temporal rate.

https://en.wikipedia.org/wiki/Frequency#Aperiodic_frequency

leeoniya• 2 years ago

mechanical watches use a weird vibrations per hour. so instead of 4hz you get an unintuitive but impressive 28,800vph

https://en.m.wikipedia.org/wiki/Vibrations_per_hour

nyrikki4• 2 years ago

Easier solution which increases your chance of being compatible with the rest of the world:

Just use the ECMAScript Language Specification's Time-related Constants algorithms like SecFromTime (t)

https://tc39.es/ecma262/#sec-time-related-constants

Even the draft of w3c's High Resolution Time just incorporate them.

https://www.w3.org/TR

The ECMAScript Language Specification algorithms will help with rounding

SI allows for Quotients of SI units using either a solidus (/) or a negative exponent.

Herz is just the reciprocal of the second, 1/s or s^-1

Just as meters per second == m/s == m*s^−1

1 Hz == ∆_Cs/9,192,631,770 1 Sec == 9,192,631,770/∆_Cs

As Hertz is just a special name for s^-1 or 1/s, one can simply use the common prefixes and be mostly in sync with common standards from place like the w3c or their incorporated sources is far better than using SI for SI's sake.

Most languages have those typedefs for their duration classes/methods/functions anyway. But the ECMAScript spec above allows you to implement one that will be inter-compatible without trying to invent new or use obscure units.

jedberg• 2 years ago

We already have a unit: RPS. Requests per second.

thadt• 2 years ago

It should be emphasized that activity measures the source disintegration rate, which is not synonymous with the emission rate of radiation produced in it's decay. Frequently, a given radiation will be emitted in only a fraction of all the decays, so a knowledge of the decay scheme of the particular isotope is necessary to infer a radiation emission rate from its activity.[1]

It's a metric for a source - not a receiver. So if we're going to use Becquerels, then we're really talking about needing to characterize the sources making the requests, not the servers receiving them. Which is great information to characterize, but still leaves us needing a metric for counting the requests seen vs those that are started but never reach the server.

If we're still excited about doing things like people measuring radiation, then we could use counts per time unit. Like, counts per second, for example.

BUT - not all requests are equal. Next up, we measure how many resources are consumed in serving each request. I expect my next system dashboard to have a metric for RES (Röntgen Equivalent Server).

[1] Knoll, 'Radiation Detection and Measurement' (3rd Ed) p2.

tussa• 2 years ago

Just because something can be counted in a fixed timeframe doesn't mean it makes sense to slap a Hz unit on it.

What's your frequency (in Hz) of sexual intimacy?

PeterStuer• 2 years ago

We alteady have time as measured in seconds. "Requests" are at best an ill defined concept measured as a discrete quantify. I see no reason to 'standardize' beyond requests per second in a given context imho.

jonathrg• 2 years ago

There is a standard for these kinds of things, the IEC-80000 part 13 defines quantities related to information science and technology. The one that is closest to request rate is probably "call intensity / calling rate".

https://en.wikipedia.org/wiki/ISO/IEC_80000#Part_13:_Informa...

This standard doesn't get much use. Mateusz Pusz, author of the C++ library mp-units, recently discovered it and has incorporated it into v2. https://www.youtube.com/watch?v=l0rXdJfXLZc

bjourne• 2 years ago

When you say that someone is 1.90 m tall what you're actually saying is that their height is given by a random variable whose expected value is 1.90 m. Usually that random variable is a Gaussian with a very small standard deviation. In case of human height perhaps 0.005 m since height varies slightly during the day and measurements are inexact. Saying the request rate is 4 Hz works the same, except here the random variable (probably) is Poisson distributed with expected value 4.

smcameron• 2 years ago

I thought qps (queries per second) was bog standard.

GlenTheMachine• 2 years ago

As a controls engineer, I strongly discourage using hertz as a measure of events. It's an abuse of notation.

In control theory and signal processing, we refer to the frequencies that make up a signal in hertz. The maximum frequency a control law can track is called its bandwidth, which is in hertz. Frequencies a filter is passing or stopping are in hertz.

Computers being digital, we have to run that control law or signal processing algorithm at some rate. That rate also gets referred to in hertz, a lot, and it is a cause of no end of confusion, because the running rate of the algorithm is very much not the same as the bandwidth or filter bandpass. The Nyquist criterion says that the algorithm has to run at least twice as fast as the frequency of interest, but practice more like ten times faster. SO when we refer to a control law as "500 Hz" or whatever, I have to explain which sense I mean every damn time.

Don't do it. Events happen at events per second. Hertz refers to sine waves, and NOTHING ELSE.

xxs2• 2 years ago

Given that any waveform can be produced out of "sine waves", we can call those events call composite sine, falling back to Hertz.

The said request most likely have originated as some sines as well, think of your phone for instance.

Seriously, though, using Hertz would be confusing to a high degree.

TylerE• 2 years ago

The sine wave thing is technically true, but if you try it in practice, as I did extensively in a college acoustics course, you’ll find that making even a decent approximation of a square or a saw wave requires sine waves at many multiples of the upper threshold of human hearing. You need those insanely high overtones to produce sharp “corners” in the wave form.

charles_f2• 2 years ago

I only count my requests in pints per fortnight.

coffeebeqn2• 2 years ago

Beers per on-call shift

bvrmn• 2 years ago

Saying “ninety kilobecquerel” and writing “90 kBq” is a lot more convenient than “ninety thousand requests per second” and “90,000 requests/s”.

I think current norm is 90k rps (or qps, but it's clear in both cases).

kragen2• 2 years ago

for some reason i got a lot of pushback when i tried to implement this terminology at a previous job

coffeebeqn2• 2 years ago

Naming things. Requests per second is clear and unambiguous

rerdavies4• 2 years ago

But the question isn't about naming things. It's about what UNITs to use.

Unhelpfully, one of the standards cited earlier suggests using the symbol 'r' for request rate. That's a symbol, which is how you would name the variable in a math or physics paper. But let's ignore that.

The base unit is 1/s, which causes all kinds of problems in SI, not the least of which is: how do you apply prefixes? μ/s, m/s, k/S, M/s, G/s?

If the unit is Bq (Becquerel), the prefix problem goes away: μBq, mBq, kBq, MBq, GBq?

rerdavies4• 2 years ago

Hopefully, anyone who is using becquerels for request rates is also using the delightfully obscure SI unit, the erlang.

https://en.wikipedia.org/wiki/Erlang_(unit)

The unit symbol for Erlang is E.

The Erlang unit is used in telecommunications, where it is used in calculations that involve queueing problems. In telecommunications, it can be used to measure the load placed on a communications channel by an average request.

This leads to the delightful identity (for those who were asking for identities):

   E = Bq/Bq[Max]

Where Bq[Max] is the the maximum possible number of requests that can be serviced in one second of CPU time if those request were serviced sequentially.

defrost• 2 years ago

So obscure it's not listed as an SI base unit nor as an SI derived unit?

https://en.wikipedia.org/wiki/International_System_of_Units

rerdavies4• 2 years ago

The Erlang unit is defined in

ISO/IEC 80000-13:2008

alongside the bit (bit), octet (o), byte (B), baud (Bd) and shannon (Sh).

The ISO/IEC 80000 series of standards supersede the old ISO 30 SI standards.

SI Units for Request Rate

Related Stories