HISTORICAL PERFORMANCE ARCHIVE / SEPTEMBER 18, 2026

Older measurements.
Still visible, clearly dated.

These campaigns remain public because transparent engineering does not discard an inconvenient result or quietly transfer an old result to a new release. They describe September builds and different test questions. They are not qualification of public v1.0.4.

Historical evidence boundary. The capacity matrix and matched-tail campaign used different builds and IRQ policies. Read each independently. Do not combine them into one capacity curve or use them as a v1.0.4 claim.

CAMPAIGN 01 / FOUR WORKLOADS

Different workloads exposed different trade-offs.

Five accepted repetitions were retained for each profile on separate load-generator, gateway and upstream instances. The gateway host ran one product at a time. The useful story is not that one system won every row: NGINX led several throughput and CPU-efficiency profiles, BonVoyage recorded lower measured tails in several small-response profiles, and the 64 KiB test reached a shared network ceiling.

Download the structured benchmark data Read the v1.0.4 replay

PROFILE 01

HTTPS / 24 CPUs / 256 B

NGINX delivered more successful requests and used less application CPU. BonVoyage had lower measured p99 and p99.9. Envoy was measured in the same five-repetition matrix.

HTTPS / 24 CPUs / 256 B historical measurements

HTTPS / 24 CPUs / 256 B · Five-run medians
Gateway	Successful RPS	p99	p99.9	App CPU
BonVoyage	775,802.89	1.631 ms	2.520 ms	101.00%
NGINX	802,500.52	1.753 ms	2.825 ms	98.71%
Envoy	313,643.9	6.321 ms	10.135 ms	100.46%

PROFILE 02

HTTP / 24 CPUs / 256 B

NGINX led throughput and application CPU efficiency on this minimal cleartext workload. BonVoyage recorded lower measured tail latency. This is not a throughput victory over NGINX.

HTTP / 24 CPUs / 256 B historical measurements

HTTP / 24 CPUs / 256 B · Five-run medians
Gateway	Successful RPS	p99	p99.9	App CPU
BonVoyage	789,516.7	1.673 ms	2.425 ms	101.05%
NGINX	866,869.03	1.873 ms	4.035 ms	84.42%
Envoy	336,564.29	5.888 ms	8.261 ms	100.30%

PROFILE 03

HTTPS / 8 CPUs / 256 B

BonVoyage delivered 9.89% more successful RPS than NGINX at this capacity point. p99.9 was effectively tied, with NGINX slightly lower. No eight-core Envoy result is included in this summary.

HTTPS / 8 CPUs / 256 B historical measurements

HTTPS / 8 CPUs / 256 B · Five-run medians
Gateway	Successful RPS	p99	p99.9	App CPU	Errors
BonVoyage	347,457.27	1.840 ms	1.976 ms	100.10%	0
NGINX	316,199.56	1.875 ms	1.969 ms	100.40%	0

PROFILE 04

HTTPS / 24 CPUs / 64 KiB

All three reached a similar network ceiling, around 11.72 Gbit/s of payload. BonVoyage used substantially more application CPU. A throughput tie is not an efficiency win.

HTTPS / 24 CPUs / 64 KiB historical measurements

HTTPS / 24 CPUs / 64 KiB · Five-run medians
Gateway	Successful RPS	p99	p99.9	App CPU
BonVoyage	22,353.07	12.422 ms	214.004 ms	60.32%
NGINX	22,332.9	10.882 ms	214.271 ms	18.57%
Envoy	22,373.19	14.563 ms	214.562 ms	23.88%

Application CPU is relative to the assigned application allowance. Slight values above 100% reflect sampling-window noise. The retained percentile statistic is the worst client lane followed by the median across repetitions, not a globally merged percentile.

CAMPAIGN 02 / A DIFFERENT QUESTION

How much traffic stayed inside the tested tail reference?

This campaign did not compare equal offered rates. It looked for the response boundary at which each system stayed inside the selected p99.9 reference. BonVoyage sustained 574,935 successful RPS versus NGINX's 499,938 RPS at the reported points, and all five BonVoyage runs stayed below NGINX's median p99.9. That is the complete scope of the historical 15% result.

Matched-tail historical measurements

HTTP/1.1 / 24 application CPUs / 256 B / five repetitions
Measured point	Successful RPS	p95	p99	p99.9	App CPU (avg core-eq)	Errors
BonVoyage / 575K offered	574,935	78.441 ms	155.274 ms	170.169 ms	23.814	0
NGINX / 500K offered	499,938	58.048 ms	203.737 ms	234.596 ms	14.921	0

Bounded reading. The result asks how much successful traffic each system kept inside the tested p99.9 reference, not which system was faster at an equal offered rate. BonVoyage used packaged tuning and NGINX used OS-managed IRQs. NGINX consumed fewer average application CPU core-equivalents; BonVoyage carried more successful requests per second at the tested p99.9 reference. Because the offered rates differed, the lower CPU observation is not an efficiency conclusion. At 600K offered RPS, one BonVoyage repetition exceeded the reference tail. Envoy was not part of this campaign.

CPU interpretation: Average core-equivalents are aggregate application CPU-seconds divided by elapsed time. They do not identify active-worker count, per-worker saturation, scheduling behavior or the cause of a latency result.

Source: AWS Response-Boundary A/B and Matched Envelope, September 18, 2026. Source commit 55c49fa600eefd3d5784b6e88507428977ee4187.

REPEATABILITY OVER THE BIGGEST NUMBER

Three isolated roles. Explicit resource budgets.

01 / Load generator Shared AWS c7a.8xlarge. Rate-controlled tests used pinned clients, coordinated-omission correction and synchronized evidence windows.
02 / Gateway target Shared AWS c7a.8xlarge. One gateway ran at a time with eight or 24 application CPUs according to the profile.
03 / Controlled upstream A separate shared c7a.8xlarge served fixed responses. A saturated supporting role invalidated the point rather than being hidden inside the result.

Accepted runs and rejected attempts

The capacity matrix retained five-repetition groups within a 5% range-over-median variation, HTTP 200 responses and support hosts below 80% CPU. An initial support-saturated run and a 64 KiB attempt with an HTTP 504 were rejected. Passing reruns did not erase those records.

Artifact and source identity

Campaign 01 source commit: 1c5259cb0fa3c12805f6047868181ed35a2ddbc2.
Gateway executable SHA-256: a054814e67058a44b179215f611e5ba620bf5d812a34472e67d535eb95117a35.

The retained source report pins the comparator images, configurations, load generator and snapshots. This website publishes a curated summary, not the raw evidence authority.

Why these are not bare-metal results

Shared-tenancy AWS c7a.8xlarge, 32 vCPUs per host does not prove physical NIC, PCIe or NUMA placement. Configured IRQ affinity and kernel-reported effective affinity can differ. Physical-host qualification requires a separate campaign.

What the archive does not claim.

Not public v1.0.4.

These numbers remain bound to their September 18 builds. Later binaries do not inherit them automatically.

Not universal superiority.

NGINX led several throughput and CPU-efficiency profiles. BonVoyage advantages are limited to the named workload and metric.

Not equal-rate proof.

The matched-tail result used different offered rates and application-core consumption. It cannot establish equal-rate latency or CPU efficiency.

Not production sizing.

Shared virtual machines and bounded workloads cannot establish dedicated-host capacity or infrastructure savings for another service.

Continue to current-release performance evidence

START WITH ONE SERVICE

Your traffic is the real test.

Bring your workload, your policies, and your latency budget.

Plan your evaluation Discuss an evaluation