"""Docker workload benchmark — host vs k7-fd vs k7-ql vs k7d vs k7d-fc. Why a pytest module rather than a separate bash harness: ``tests/integration/test_docker.py`` already pioneered the pattern of spinning up a sandbox with Docker and running docker commands via ``k7_core.exec_command``. This benchmark times that same pattern. k7d and k7d-fc use first-class ``--docker`` (guest agent dockerd, overlay2 on a virtio-blk graph disk, forkable). Kata backends use the same ``--docker`` flag via a privileged docker-vehicle container and a block graph (overlay2): Longhorn Block PVC on kql, ephemeral LVM thin LV on kfd. Why these environments are valid: ``test_sidecar_docker.py`` has a note claiming Docker-DinD doesn't work on the Firecracker backend. That note is historical — ``k7 create --docker`` now lands on the vehicle, not ``docker:27.5-dind``. The isolation we want: - ``k7-fd`` — docker-in-VM without Longhorn in the storage path. - ``k7-ql-r1`` — adds Longhorn r=1 (one local replica). - ``k7-ql-r2`` — adds Longhorn r=2 (one local + one cross-node sync). - ``k7-ql-r3`` — Longhorn r=3 (replicas on all three nodes of an HA cluster — the full redundancy write-amplification cost). - ``k7d`` — first-class ``--docker``: dockerd is an agent child, graph on a per-sandbox virtio-blk scratch disk (overlay2, not tmpfs). Needs enough ``--memory`` for the engine; layers live on the graph disk. Fork of a warm engine is in-scope. - ``k7d-fc`` — same guest docker service as ``k7d``, RuntimeClass ``k7-fc`` (stock Firecracker + jailer). Overlay2 and warm fork of a running inner engine must match native k7d. Marker / invocation: This file uses ``@pytest.mark.bench`` so it doesn't run with the rest of ``-m integration``. Drive it explicitly: K7_BENCH_ENVS=host,k7-fd,k7-ql-r1,k7-ql-r2,k7-ql-r3,k7d,k7d-fc \\ K7_BENCH_OUT=/tmp/bench-out \\ uv run pytest -m bench tests/integration/bench_docker_perf.py -v Replica counts are applied per sandbox volume by patching the Longhorn Volume CR's ``spec.numberOfReplicas`` after creation (the ``longhorn`` StorageClass pins ``numberOfReplicas`` as a provisioning parameter, so patching Longhorn's ``default-replica-count`` setting has no effect on these volumes). Each ql log header records the actual replica placement. Output: one ``bench-