A transcode is re-run for every request, so throughput is 1% of upstream's #191
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The number
#117wanted first: how many concurrent transcoding sessions thisserver sustains against upstream's. It is not measurable yet, and the reason is
no longer hardware.
transcoding.jsonruns on both servers and the gate refuses to time any of it,because the two write different files for the same request — measured, and
filed as
#190:Timing two servers that produce different output compares two different pieces
of work, so the gate is right to drop them.
#190is the blocker; this issueis the measurement waiting behind it.
The other half is the fixture: the reference library is nineteen clips of five
seconds, which is enough to prove a transcode starts and not enough to saturate
anything. A throughput number needs media a session can actually run against
for the length of the measurement.
How to know it is done
Sessions sustained at each concurrency point, both servers pinned to their own
cores on one host, with the gate agreeing on every request before anything is
timed — and the ffmpeg both are pointed at recorded with the result.
House rules
Tests run under
cargo nextest; upstream's source is the checkout inupstream/at the pin.Unblocked and measured — and the answer is that this server does not sustain
them.
#190was the blocker and it is fixed (a764076): the whole transcodingrequest set now agrees, six of six, so the gate lets the workload be timed for
the first time.
cargo xtask bench --fixture default --workload transcoding, both serverspinned to their own cores, one repetition, ten seconds a point, the reference
library's clips:
Upstream climbs to ~240 requests a second and stays there; ours is flat at
~2.9 from c=4 up, with a p99 of over a minute at c=128. Bytes per response
agree to within a percent, so both are answering with the same work — ours is
simply doing it again for every request where upstream is not.
That is the shape of a job that is not being shared: the same request asked
twice should join the encoder already writing that file rather than start
another. The progressive path names its output after what decides it precisely
so a second request can join, so this is either that join not happening or a
queue in front of it.
Two things this run is not:
ratio is about scheduling rather than encoding speed.
so this measures the cost of starting and joining work, which is the part
that collapsed. A library with real runtimes would say what a sustained
session costs.
The measurement this issue asked for now exists. What it found is a performance
defect rather than a missing fixture, and that is what is left here.
Unblocked and measured — and the answer is that this server does not sustain
them.
#190was the blocker and it is fixed (a764076): the whole transcodingrequest set now agrees, six of six, so the gate lets the workload be timed for
the first time.
cargo xtask bench --fixture default --workload transcoding, both serverspinned to their own cores, one repetition, ten seconds a point, the reference
library's clips:
Upstream climbs to ~240 requests a second and stays there; ours is flat at
~2.9 from c=4 up, with a p99 of over a minute at c=128. Bytes per response
agree to within a percent, so both are answering with the same work — ours is
simply doing it again for every request where upstream is not.
That is the shape of a job that is not being shared: the same request asked
twice should join the encoder already writing that file rather than start
another. The progressive path names its output after what decides it precisely
so a second request can join, so this is either that join not happening or a
queue in front of it.
Two things this run is not:
ratio is about scheduling rather than encoding speed.
so this measures the cost of starting and joining work, which is the part
that collapsed. A library with real runtimes would say what a sustained
session costs.
The measurement this issue asked for now exists. What it found is a performance
defect rather than a missing fixture, and that is what is left here.
How many transcoding sessions this server sustains is still not measuredto A transcode is re-run for every request, so throughput is 1% of upstream'sFixed in
93b8e15, and the number turned round.The cause was not scheduling. Every request re-ran ffmpeg over a file it had
already written: upstream's
GetTranscodedFilestarts an encoder only when theoutput is not there, and ours started one unconditionally. The check now happens
under the lock a start is taken under, so a request that finds the file serves
it and holds no job.
Same run as the measurement above, same fixture, gate agreeing on all six
requests both times:
Bytes per response are 1.00 of upstream's at every point, so this is the same
work being answered rather than less of it. Ours ran 6 encoder processes for
the whole run; upstream ran 5010.
Why upstream runs so many, and where the two now differ. Upstream names a
progressive output after
mediaPath-userAgent-deviceId-playSessionId(
StreamingHelpers.cs:377), so it reuses a transcode within one play sessionand re-encodes for the next. Ours names it after what the request asked for, so
it reuses across sessions until the transcode sweep takes the file a day later.
That is a deliberate difference and it is what the six runs against five
thousand is measuring — the answers themselves agree byte for byte.
The reference library's clips are seconds long, so what this measures is the
cost of starting work rather than of sustaining an hour of it. A library with
real runtimes would say what a long session costs; that is a fixture question
rather than a code one, and it is
#192's neighbour.