Longer Linux runs refine the Ada HTTP result.

This follow-up extends the preliminary three-second Docker snapshot to two architectures, seven trials, 30-second measurements, five-second warmups, and 20-second cooldowns. Every included request returned the expected HTTP 200 response and exact body.

The ARM64 host used Neoverse-N1 processors with 80 physical and 80 logical cores and 256 GB of memory. The AMD64 host used an Intel Xeon Gold 5412U with 24 physical cores, 48 logical CPUs, and 256 GB of memory. These are whole-machine totals, not resources reserved exclusively for the benchmark.

Each container had a 16-CPU quota, but not an exclusive CPU set. The server was pinned to CPUs 0–7 and the client to CPUs 8–15 within the container.

The comparison stayed apples-to-apples.

The plain tier compares direct HTTP handlers: Flyology's raw connection handler, AWS's callback API, and EWS's dynamic handler API. The application tier compares Flyology's router and exchange API with one identical ServletAda servlet running over AWS and EWS.

Transport

HTTP/1.1 cleartext over loopback with persistent connections; no TLS or connection churn.

ARM64 machine

Neoverse-N1, 80 physical / 80 logical cores, and 256 GB of memory.

AMD64 machine

Intel Xeon Gold 5412U, 24 physical / 48 logical cores, and 256 GB of memory.

Responses

An exact 13-byte body and exact 1 KiB body in the plain tier; one routed GET in the application tier.

Campaign

Seven trials, five-second warmups, 30-second measurements, and 20-second cooldowns.

Flyology

Sixteen event loops; lightweight and native task lanes measured separately.

Validity

Only rows with a 100% HTTP success rate enter the comparison table.

Flyology led every valid peer row.

At concurrency one, Flyology's faster lane led the tested peer fixtures in both tiers and on both architectures. Which Flyology lane was faster changed with architecture: native led on ARM64, while lightweight led on AMD64.

The 1 KiB plain response kept the same peer ordering. Complete medians, ranges, and latency percentiles are in the downloadable CSV rather than compressed into a single headline number.

Lightweight is the efficiency result, not a universal throughput winner.

Lightweight used two server threads in every run; native used 257. Across the two plain workloads, lightweight accumulated 52.7 CPU seconds on ARM64 and 51.6 on AMD64. Native accumulated 186.2 and 212.5 seconds respectively.

That lower footprint did not force one throughput outcome. Lightweight delivered about 90% of native plaintext throughput on ARM64 and 106% on AMD64. The routed application tier followed the same pattern. Native remains a performance tool when its OS-thread cost is appropriate; lightweight is compelling when throughput, CPU use, and thread count are considered together.

The common higher-concurrency table did not survive.

The runner advances only after every fixture passes a strict 100% success threshold. At concurrency eight, the first EWS plaintext measurement recorded 20 five-second request timeouts on ARM64 and 23 on AMD64, alongside hundreds of thousands of successful responses. Those success rates were close to—but not equal to—100%, so the runner stopped.

We therefore exclude concurrency eight and 32 from this follow-up. The result is not “EWS scores zero,” nor evidence that EWS has a universal concurrency limit. It says only that this exact fixture did not pass this campaign's validity gate on the shared hosts. Reporting that boundary is more useful than filling a chart with incomparable rows.

This still measures HTTP overhead, not a complete service.

The endpoints do almost no application work. They do not query a database, call a remote service, use TLS, serialize a meaningful object, or rotate connections. A database-backed endpoint could change the balance: nonblocking waits should suit lightweight tasks, while a blocking client library belongs behind a bounded native-task boundary.

The hosts were shared and the CPU quota was not an exclusive reservation. Cross-architecture numbers describe two separate environments and should not be read as a processor comparison. A dedicated-host campaign remains the right next step for stronger absolute claims.

Bring your own two Linux nodes.

The generic runner creates an isolated namespace, builds the benchmark image once per architecture, runs the campaign, copies the artifacts, and removes the namespace.

HTTP_BENCH_ARM64_NODE=<arm64-node> \
HTTP_BENCH_AMD64_NODE=<amd64-node> \
HTTP_BENCH_TRIALS=7 \
HTTP_BENCH_DURATION=30s \
HTTP_BENCH_WARMUP=5s \
HTTP_BENCH_COOLDOWN=20 \
HTTP_BENCH_CONCURRENCIES=1 \
HTTP_BENCH_SERVER_CPUSET=0-7 \
HTTP_BENCH_CLIENT_CPUSET=8-15 \
HTTP_BENCH_LOOPS=16 \
  ./showcases/http-comparison/scripts/run-kubernetes.sh

Read the comparison guide before substituting hosts or changing the validity threshold. The fixture source used for these measurements is pinned in the article metadata.