WorkManager pipeline benchmarks

These measure the real path a worker sees: a publisher sends CloudEvents to a topic, the API fans them out (Redis/Dapr), the Runtime enqueues them and calls the worker's actor turn, the worker returns a marker event, and a subscriber receives it. The worker is the same no-op marker used on the engine page, so anything measured here is the pipeline, not the worker's business logic.

Fixed rate

The publisher offers a known rate (for example 50 events/s) for a fixed window. This shows whether the pipeline keeps up at that load and how long an event takes end to end:

• events/s — markers received ÷ window; below the offered rate means the pipeline fell behind;
• p50/p95/p99 — publish → marker receive, including queueing at every hop; a p99 far above p50 is backlog building up;
• delivered/offered — loss or timeout (dead letters are counted as errors, not delivered).

Saturation

The publisher sends a batch of events as fast as it can (batched PublishEvents calls) and waits for all markers. This is the pipeline's ceiling for this deployment:

• events/s — delivered ÷ (publish time + drain time);
• publish s / drain s — how much of the window was the publisher versus the workers draining the backlog;
• errors — events still undelivered at the drain deadline.

The pipeline currently runs against the dedicated virtufin-benchmark namespace (api/workmanager/runtime, one replica each). Its replica count and Redis bound the result; that is the point of an isolated baseline, and the numbers are not comparable with the engine page.

History

text/x-csharp — fixed rate

text/x-python — fixed rate

text/x-typescript — fixed rate