stzPerfProfile

(no comment in the source: the name reads as a sentence) initno extension

Re-anchor: the next answers cover a fresh interval from NOW. The timer's exact lifetime sum/count are anchored too, so the interval's mean R and the interval's D describe THE SAME requests -- mixing a lifetime R with an interval D would make the computing/waiting split compare different populations.no extension

(no comment in the source: the name reads as a sentence) monitor qno extension

The interval factsno extension

Requests completed since the anchor.no extension

X -- requests per second over the interval.no extension

CPU actually consumed over the interval, in ms (all threads).no extension

U -- the fraction of the MACHINE this process used.no extension

D -- the diagnostic number: CPU-ms each request consumed. 0 when no requests crossed the interval (nothing to attribute).no extension

Where this machine saturates IF CPU is the constraint (req/s).no extension

The demand signal for elastic scaling (perf P6): how close this workload is to its CPU ceiling, X/Xmax in 0..1. This is what stzClusterSupervisor.ReportLoad() always wanted -- MEASURED, not hand-fed: FeedLoadFrom(tag, oProfile) closes the loop. 0 when nothing is measurable yet (no requests / no demand). (Named LoadRatio: `load` is a Haro keyword.)no extension

1 - X/Xmax: how much of the CPU ceiling remains (0..1).no extension

The self-checks ------------------------------------------ The utilization law, checked for real: anchor-computed U vs the monitor's independently SAMPLED utilization gauge. From one set of anchors U = X*D/cores is an identity (no information); two independent measurements agreeing is evidence the measurement itself is sound. Returns [ :computed, :sampled, :consistent, :message ]; sampled = -1 when the gauge is not watched/sampled.no extension

N -- the average requests in flight IMPLIED by Little's law (X * mean R). What you should see if you counted concurrency.no extension

Compare the implied N with a concurrency you MEASURED elsewhere (e.g. a worker pool's InFlight()). Same-scale consistency: within a factor of 3 (floored at 0.05 -- tiny numbers agree).no extension

R, and the computing/waiting split ----------------------- Mean R over THE INTERVAL (exact: the timer's anchored sum/count deltas) -- the same requests D is computed over. Percentile methods answer over the timer's retained window (stated in Explain); the mean is the interval's own.no extension

(no comment in the source: the name reads as a sentence) response time p50no extension

(no comment in the source: the name reads as a sentence) response time p95no extension

(no comment in the source: the name reads as a sentence) response time p99no extension

Of each request's R, the part that was NOT computation: waiting on IO, locks, sleeps, the queue. R - D, floored at 0.no extension

The first question of every investigation -- busy or blocked? -- answered with the split: a request's time goes to CPU (D) or to waiting (R - D); the larger share names the constraint.no extension

Memory: trend and forecast ------------------------------- Bytes per hour the rss gauge is trending (needs WatchMemory + samples). Positive = growing: the slow-leak number.no extension

At the current trend, hours until rss reaches pnCeilingBytes. 0 = already at/past the ceiling; -1 = not growing (never, at this trend).no extension

The R-vs-X curve ----------------------------------------- Record one (X, R) point for the CURRENT interval -- drive different load levels and Snapshot() after each; Curve() shows where response time turns as throughput climbs.no extension

[ [ atMs, X, U, D, Rp95 ], ... ] in recording order.no extension

The narrated analysisno extension

(no comment in the source: the name reads as a sentence) showno extension