feat: add HTTP readiness latency benchmark

[jim-junior]

This PR adds an HTTP readiness latency benchmark adapter.

The benchmark measures how long a container takes to become ready to serve HTTP requests. Measurement begins immediately before the OCI start command is invoked and ends when the container returns its first HTTP 200 OK response.

How It Works

The adapter uses the CLI-based execution path with nerdctl instead of the Go containerd API.

The benchmark performs the following steps:

1. Creates the container.
2. Starts an HTTP readiness probe in a goroutine.
3. Records the start time immediately before invoking the container start command.
4. Continuously sends HTTP GET requests to the container URL.
5. Waits until the first HTTP 200 OK response is received.
6. Records the readiness latency and total number of attempts.

Only HTTP 200 OK is considered a successful readiness response.

The probe ignores:

• Connection refused errors
• Connection reset errors
• Request timeouts
• HTTP 4xx responses
• HTTP 5xx responses
• Any other non-200 HTTP response

Container Images

Runtime	Image
runc	docker.io/library/nginx:latest
Kata Containers	docker.io/library/nginx:latest
gVisor	docker.io/library/nginx:latest
urunc	harbor.nbfc.io/nubificus/urunc/nginx-qemu-unikraft-initrd:latest

Readiness Latency Definition

HTTP readiness latency = time of first HTTP 200 response - time immediately before the OCI start command

This represents the time taken for the containerized HTTP server to become available after the runtime start operation is invoked.

Output Format

The readiness data is recorded in the adapter's Wait Ready stage.

Example:

{
  "attempts": 482, // Number of HTTP requests made before receiving the first 200 OK response
  "end": "2026-08-02T15:45:24.768593448+03:00",
  "latency": 1893693110,
  "latency_ms": 1893.693,
  "readiness_latency": 1893693110,
  "readiness_latency_ms": 1893.693,
  "ready_at": "2026-08-02T15:45:24.768593448+03:00",
  "start": "2026-08-02T15:45:22.874900338+03:00",
  "status_code": 200,
  "url": "http://127.0.0.1:8082/"
}

[cmainas]

Hello @jim-junior ,

I have added a few comments. One thing that I did not see is the cleanup of the container, which might take place somewhere else in the code. However, if it does not =, we should clean up the containers we start. There is also the danger of getting wrong measurements due to a stale container which still listens portMapping in the localhost.

Another comment for future reference is that the code can be simplified. But we can do that in future iterations.

[jim-junior]

Hello @cmainas

• I have moved the code snippet that records the start time closer to when the container is started.
• ALso added cleanup code, that removes any containers and log files created by the harness, incase its fails or meets an error
• I also added a cmd.Wait() go routine function, You had mentioned of this here: feat: add network performance benchmark #4 (comment)

[cmainas]

Thank you @jim-junior !