# Ingress controller core additions: unused-feature regression check, 2026-10-14

URL: https://scalws.com/docs/benchmarks/2026-10-14-xeon-ingress-core-regression/
Source: `docs/benchmarks/2026-10-14-xeon-ingress-core-regression.md` in the ScalWS repository

This file holds two rounds: the first run (HEAD 7b7b57e, kept as history) failed the gate on
respond; the second round (fix 2ab0e83) is under "Round 2" at the end.

Machine, pinning and method as in `2026-10-14-xeon-routing-pools-regression.md`: 2× Xeon
E5-2650 v2, `performance` governor, turbo off. Server on CPUs 0-3 (4 workers), upstream
and applications on 4-7, `oha` 1.16.0 on 8-15 and 24-31, 64 connections.

Commits: `base` = 90642de (main before the ingress controller branch), `new` = 7b7b57e
(catch-all domain `*`, route `https_redirect`, and the rest of the branch). Both are plain
release builds (`cargo build --release --locked -p scalwsd --features http3`, thin LTO, no
PGO or BOLT), so the numbers are only comparable with each other.

Configuration: `bench/configs/scalws.yaml` unchanged, so neither the catch-all domain nor a
route `https_redirect` is configured. `bench/multi.sh`, `MODE=release` (10 s warm-up, 30 s
measurement, 5 runs, variant order rotating), medians. Every measurement answered 2xx only;
no run was excluded.

Gate: `new` requests per second at least 0.98× `base`.

| scenario | base req/s | new req/s | new / base | cpu_us base | cpu_us new | cpu new / base | gate |
|---|---:|---:|---:|---:|---:|---:|---|
| static-small | 74 783 | 74 123 | 0.991 | 53.48 | 53.95 | 1.009 | pass |
| respond | 126 492 | 123 110 | 0.973 | 31.62 | 32.48 | 1.027 | FAIL |
| proxy | 50 743 | 50 567 | 0.997 | 78.82 | 79.09 | 1.003 | pass |
| cache-hit | 93 627 | 92 151 | 0.984 | 42.72 | 43.39 | 1.016 | pass |

Spread of the five runs (req/s, min to max, CV): static-small base 74 396-76 116 (1.0 %),
new 73 069-74 838 (1.0 %); respond base 124 855-127 209 (0.7 %), new 120 906-124 099
(1.0 %); proxy base 49 828-51 100 (1.0 %), new 49 593-50 679 (0.9 %); cache-hit base
92 579-94 137 (0.6 %), new 91 058-93 332 (1.0 %).

p99 latency (ms), base / new: static-small 1.09 / 1.06; respond 0.64 / 0.66; proxy
2.00 / 1.94; cache-hit 0.90 / 0.87.

Peak resident memory (MiB), base / new: static-small 43 / 43; respond 42 / 42; proxy
48 / 49; cache-hit 48 / 49.

## Repeat of respond

The respond scenario alone, same method, 5 more runs: base 126 515 (122 009-127 194, CV
1.7 %), new 123 535 (120 376-125 106, CV 1.4 %), ratio 0.976, cpu_us 31.61 / 32.37 (1.024),
p99 0.60 / 0.65 ms. The drop reproduces, so it is not a one-off.

## Verdict of round 1

The gate does not hold for respond (0.973 and 0.976, CPU per request +2.4 % to +2.7 %).
static-small, proxy and cache-hit pass; cache-hit (0.984) is close to the limit.

The code paths that differ for a configuration without `*` and without route
`https_redirect` are small: the host lookup does the same exact-match hash lookup first
(the `catch_all` field is only read after an exact and a wildcard miss), and the
plain-HTTP branch in `pipeline.rs` reads one extra `bool` (`route_https_redirect`) before
falling back to `app.https_redirect`. Neither is expected to cost about 0.8 us per
request, so a layout or inlining effect of the changed request function is the likely
cause, but this is not confirmed: no profile was taken in this run (see the follow-up in
the task report).

Results, in the bench host's results directory: `results/xeon-ingress-ab` and
`results/xeon-ingress-ab-respond` (`aggregate.csv`, `aggregate.txt`,
`run-N`); binaries `/opt/scalws-ingress-base/scalwsd` and
`/opt/scalws-ingress-new/scalwsd`.

## Round 2: hot path restored (2ab0e83)

Changes, no behaviour change: `AppEntry.redirect_check` (`https_redirect` or any route
`https_redirect`) is precomputed, so the hot path is again one flag test
(`if app.redirect_check && scheme == Http`), and the route lookup and decision moved to a
`#[cold] #[inline(never)]` helper `wants_https_redirect`. In `HostRouter` the exact hit is
unchanged and the wildcard and catch-all tail is an out-of-line `get_fallback`. Tests
(`scalws-router`, `scalws-server`, integration `routing`), fmt and clippy pass.

A/A noise (base binary against itself, respond, 5 runs): 125 585 against 124 786, ratio
0.994, run ranges 121 110-127 283 and 123 310-125 491 (min to max about 5 %). A/A cache-hit:
95 805 against 95 855, ratio 1.000. Single A/B medians therefore move by about 1 % without
any code difference.

A/B, all four scenarios, 5 runs (`xeon-ingress-ab2`):

| scenario | base req/s | new req/s | new / base | cpu_us base | cpu_us new | cpu new / base | gate |
|---|---:|---:|---:|---:|---:|---:|---|
| static-small | 75 016 | 74 522 | 0.993 | 53.31 | 53.66 | 1.007 | pass |
| respond | 126 651 | 124 945 | 0.987 | 31.57 | 32.00 | 1.014 | pass |
| proxy | 50 159 | 50 324 | 1.003 | 79.74 | 79.47 | 0.997 | pass |
| cache-hit | 94 741 | 92 803 | 0.980 (0.9795) | 42.21 | 43.08 | 1.021 | borderline |

cache-hit landed on the limit (0.9795 unrounded), so it was repeated alone
(`xeon-ingress-ab2-cache`): base 95 874, new 94 960, ratio 0.991, cpu_us 41.71 / 42.11
(1.010). Across the three cache-hit A/B runs the ratio is 0.984, 0.980, 0.991; the A/A
ratio is 1.000. Peak RSS equal within 2 MiB; p99 equal within noise. No perf profile was
taken since the gate holds on the repeat.

Results, in the bench host's results directory: `results/xeon-ingress-{aa-respond,ab2,ab2-cache,aa-cache}`.