Serverless Platforms Under Realistic Load: A Comparative, Multi-Architecture Evaluation of Knative and Dirigent Across Runtimes Using FaaSRail

Abstract

A recent claim holds that the general-purpose Kubernetes control plane is the wrong foundation for Function-as-a-Service workloads, and that a purpose-built cluster manager, Dirigent, schedules sand- boxes orders of magnitude faster than a Kubernetes-based platform such as Knative. The evidence for it was gathered under narrow conditions: synthetic functions that busy-loop for a trace-drawn duration, Knative measured on containers only, and one processor architecture. This thesis tests the claim under a realistic, trace-derived workload of real functions. Doing so first required building the apparatus a fair test needs: a Firecracker runtime for Dirigent that executes unmodified FunctionBench functions with snapshot support, and the completion of the FaaSRail pipeline for HTTP-served platforms, including the reqgen component and the load-generator support that drives both platforms from one specification. The evaluation holds the function set, payloads, load specification, and resource limits fixed while varying platform, isolation runtime, snapshot mode, and processor architecture across amd64 and arm64. Dirigent’s advantage survives the harder test, but it is narrower and more conditional than the headline figures suggest. The platforms separate by an order of magnitude in the latency tail rather than the hundreds- or thousand-fold reported for scheduling alone, and the cause is latency in Knative’s activation and scheduling path, not control-plane CPU, which stays near-idle on both platforms. Changing the isolation runtime does not change which platform wins: Dirigent holds a bounded tail and Knative does not on both containers and microVMs, and the two runtimes are reported on their own terms rather than ranked, since the runtime also fixes part of the environment a function runs in. Snapshots cut cold- start latency by five to six times and restore a guest faster than even a container boots, yet they barely move a warm-dominated aggregate, and once they make sandbox creation cheap they expose a network- pool exhaustion failure in Dirigent’s own runtime. Every finding reproduces on both architectures. The broader result is methodological: a narrow benchmark can overstate a platform’s advantage and hide the failure modes of the platform it favours, and only an end-to-end, trace-driven measurement shows either.