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.
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.
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.
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.
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...
Being careful to distinguish 'fundamental laws' from just 'quantities that we defined', information theory and queueing theory have some good examples of proven laws.
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.
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.
> 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.
This follows the best practice of submitting a link and posting your opinion in a comment to stand on its own. This way we can all judge which viewpoint we agree with independently.
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.
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
And that brings up the difference between frequency and angular frequency.
When you use hertz meaning ‘cycles per second’ it’s far more natural to associate it with an angular velocity of 2pi radians per second - which throws a bit of a spanner in the dimensionless works, and makes it feel like using 1/2pi as a radian makes more sense.
Seems like that’d be the default assumption - I pay zero point one bucks per kWh, of course it’s an amount. What’s more interesting is kW/h, it feels like a rate but it’s more like an acceleration.
Like he said, it would measure the rate of change between two kilowatt levels. You might ask questions like "how quickly can this power plant adjust the amount of power it's producing?", and the answer would take the form of an amount of power over an amount of time.
This is one of the most salient ways in which different types of power plants differ; it's something that people are very concerned with.
Dimensionally, "liters of gasoline per 100km" and "miles per gallon of gasoline" are already stated in simplest form. Your only hope of demonstrating that a car's fuel efficiency can be measured in "liters per 100km", as opposed to "liters of gasoline per 100km", is to show that the car will function just as efficiently no matter what you put in the fuel tank, that if you put in a liter of sand you can drive just as far as if you put in a liter of gas. Among other problems, if you tried to cancel the linear kilometers of the denominator with one dimension of the liters of gasoline in the numerator, you'd end up with incompatible units being paired together. Gasoline can't be measured in two-dimensional units, and there is no "linear gasoline" in the denominator that would let you transform the gasoline in the numerator anyway.
You see this problem pop up all the time in chemistry, where a mole of some substance and a mole of some other substance are incompatible units. There is no such unit as "mole", only "mole of [whatever]". But there are people who would like to believe that "mole" is a unit.
(In contrast, there is such a unit as "liter", but it isn't used in fuel efficiency ratings.)
Okay, let’s humor this new lGas unit and see if it works.
If my engine consumes 10lGas/100km when traveling at 100km/h, that means it uses 10lGas/h, or .002778 lGas/s.
If the pipe feeding my engine has a cross sectional area of 10^-6m^2, how fast is the gasoline flowing through that pipe?
Naively I would expect I could divide flow rate by area to get mean velocity. But I’m expecting the result to be in m/s. But if I divide .002778 lGas/s by 10^-6m^2 I get 2778lGas/sm^2.
Unless an lGas is 10^-3mGas^3 and I can measure gas area in mGas^2, so I can get my gas speed in mGas/s?
If you want a mathematical way to capture ‘of gasoline’ the right way to think of it is not as a unit dimension but rather as a basis vector, kinda like ‘up’ or ‘across’.
1m * up is the vector quantity ‘1m up’, which has dimension ‘length’. 1m * across is the vector quantity ‘1m across’ which also has dimension length (we call it a displacement, but it’s a vector in the length dimension). We can add them together even though they point in different directions because they share the same dimension. The result is the vector quantity ‘1m up and 1m across’ and it is also a length.
Similarly 1l * of gas is a vector quantity ‘1l of gas’ with dimension ‘volume’. I can add it to ‘1l of air’ to get ‘1l of gas plus 1l of air’ which is still a vector volume. It might describe the contents of my fuel tank when it’s half empty for example.
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.
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.)
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.
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.
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.
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!
"By the end of that summer of 1983, Richard had completed his analysis of the behavior of the router, and much to our surprise and amusement, he presented his answer in the form of a set of partial differential equations."
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.
No, while the Mendenhall order 1893 defined all US customary units off of the Metric system, in SI "Derived units" are defined as products of powers of the base units.
If you look at section 2.3.4 in the link below you will notice that there are no scalars in those derived units.
They will all have the form:
x^n * y^m * z^o
Also note how they define a 'degree Celsius' which is equivalent to a degree K, but then invoke a T_0 to include it to avoid breaking the above rule.
The M16 is capable of about 900 rounds per minute, which is about 15 rounds per second, so we can call the Si "banana" the "M16" in America and have it be the same measure of requests per second.
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.
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.
> 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.
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.
> 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.
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.
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".
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
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.
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.
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.
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?
yeah, i mostly wanted to be able to use abbreviations: 'given that this process has an error rate of about 3 μBq, and it's invoked with a frequency of about 1 mBq, it seems like it fails about one out of every 300 times'
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.
96 comments
[ 4.8 ms ] story [ 178 ms ] threadIn 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/
I think what we are really after is yoctomole Becquerels.
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.
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?
See also https://www.nist.gov/publications/quantities-and-units-softw...
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
Depends what system you’re analysing. But the dimensional validity of that statement is applicable in numerous circumstances.
The medium used for flow isn't important for that calculation at all. Just as it would be for liters per second.
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.
> The applicable SI unit therefore is just the reciprocal second, s^(-1).
That's the hertz.
When you use hertz meaning ‘cycles per second’ it’s far more natural to associate it with an angular velocity of 2pi radians per second - which throws a bit of a spanner in the dimensionless works, and makes it feel like using 1/2pi as a radian makes more sense.
Score another point for tau I guess.
It's not algebraically incorrect, but it contains something dangerously wrong connotations about what kind of data it is.
https://xkcd.com/687/
A watt is just a joule per second. Making 1 kWh === 3.6 MJ.
This is one of the most salient ways in which different types of power plants differ; it's something that people are very concerned with.
In the US we use miles per gallon, which is the inverse - a ‘per area’.
You see this problem pop up all the time in chemistry, where a mole of some substance and a mole of some other substance are incompatible units. There is no such unit as "mole", only "mole of [whatever]". But there are people who would like to believe that "mole" is a unit.
(In contrast, there is such a unit as "liter", but it isn't used in fuel efficiency ratings.)
If my engine consumes 10lGas/100km when traveling at 100km/h, that means it uses 10lGas/h, or .002778 lGas/s.
If the pipe feeding my engine has a cross sectional area of 10^-6m^2, how fast is the gasoline flowing through that pipe?
Naively I would expect I could divide flow rate by area to get mean velocity. But I’m expecting the result to be in m/s. But if I divide .002778 lGas/s by 10^-6m^2 I get 2778lGas/sm^2.
Unless an lGas is 10^-3mGas^3 and I can measure gas area in mGas^2, so I can get my gas speed in mGas/s?
If you want a mathematical way to capture ‘of gasoline’ the right way to think of it is not as a unit dimension but rather as a basis vector, kinda like ‘up’ or ‘across’.
1m * up is the vector quantity ‘1m up’, which has dimension ‘length’. 1m * across is the vector quantity ‘1m across’ which also has dimension length (we call it a displacement, but it’s a vector in the length dimension). We can add them together even though they point in different directions because they share the same dimension. The result is the vector quantity ‘1m up and 1m across’ and it is also a length.
Similarly 1l * of gas is a vector quantity ‘1l of gas’ with dimension ‘volume’. I can add it to ‘1l of air’ to get ‘1l of gas plus 1l of air’ which is still a vector volume. It might describe the contents of my fuel tank when it’s half empty for example.
The Becquerel is also s^-1.
All in all the Bq is a cool unit! I learned something today.
It is indeed the unit of “activity”, not rate.
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.
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.
counts per second is common in particle physics
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.
"By the end of that summer of 1983, Richard had completed his analysis of the behavior of the router, and much to our surprise and amusement, he presented his answer in the form of a set of partial differential equations."
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.
This is because a banana has around 12 - 18 Becquerels of radiation. 16 is a nice power of 2 number.
If you look at section 2.3.4 in the link below you will notice that there are no scalars in those derived units.
They will all have the form:
x^n * y^m * z^o
Also note how they define a 'degree Celsius' which is equivalent to a degree K, but then invoke a T_0 to include it to avoid breaking the above rule.
https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-...
Since there are multiple versions, we use the latest and greatest: the M16A4. It is 39.97 inches long.
That‘s what American distances and lengths are measured in! I‘m 1.9 M16s tall!
After a while we swap M16 for meters, since the M16 is not only 39.97in, but also -quelle surprise!- exactly one meter long.
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
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.
> 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
https://en.m.wikipedia.org/wiki/Vibrations_per_hour
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.
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.
What's your frequency (in Hz) of sexual intimacy?
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
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.
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.
I think current norm is 90k rps (or qps, but it's clear in both cases).
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?
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):
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.https://en.wikipedia.org/wiki/International_System_of_Units
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.