[rmcdaniel]

Cloud's rc.3 performance qualification on November 2 (run dw-bench-rc3-20261102), using the #941 rc3 profiles at 8f5ac120. Full write-up: benchmarks/server-port/rc3/observations-2026-11-02.md.

What's added (data only, no code):

• One summary per small-host run from summarize-server-port-small-host.py at 8f5ac120, plus two vc2 native reruns (-r2). All 11 summaries carry profile_sha256 520f4157….
• The matched four-vCPU tables from summarize-server-port-matched.py.
• The observations note and a README pointer.

Results:

• Sustained capacity on the AMD plans matches rc.2 exactly: vhp-1c-1gb native-mysql 4 / native-sqlite 8, vhp-1c-2gb 4 / 4. PHP 2.11.8 sustains no rate on any 1-vCPU plan.

• rc.3's cost per workflow equals rc.2's. On vhp-1c-1gb at 1/s the server used 0.099 vs 0.096 cores, MySQL 0.183 vs 0.180, and SQLite 0.080 vs 0.0795.

• vc2-1c-1gb sustained 1 / 2 against rc.2's 2 / 4, and the reruns reproduced this at low steal (1–3%, sampled per window). On that instance the unchanged MySQL image needed about 25% more CPU for the same work, and the server did too. The note therefore attributes the gap to the instance, not rc.3; vc2 remains capacity-only evidence.

• Matched 4c at 1/s:

  Measure	rc.3	PHP
  p50	0.104 s	0.556 s
  Runtime CPU per workflow	0.08 core-s	0.79 core-s
  Memory	about 7 MiB	about 200 MiB

  Every window passed for both. This does not reproduce November 2's PHP collapse at 4 vCPUs; the note says so explicitly.

• The driver's NTP offset was 11–36 ms against the 5 ms tolerance, so cross_host_timing_reliable is false for every run. Capacity and resource figures stand; driver-relative latency is excluded.

rc.4 and 3.0.0 (source 74145425) differ from rc.3 only by #939's schedule next-fire math, which this workload doesn't use.

Privacy and cleanup: the summaries contain no host or IP addresses, and raw results stay private. All four hosts, the VPC, the firewall group and the SSH key are deleted, with absence verified by ID and run tag.

[rmcdaniel]

Server data check of 04038271: spot-checked summaries match the note. vhp-1c-1gb native SQLite is 8 and native MySQL is 4, vc2 native MySQL r2 is 1, and every native run uses the rc.3 index 899b404b. The rc3 profiles are unchanged, and the README only adds a pointer to the results. The vc2 attribution (equal per-workflow cost on the AMD plans, and a slower vc2 instance with low sampled steal) is stated as evidence rather than a claim. Clear from Server. These results carry to rc.4 and 3.0.0 under the agreed schedule-only runtime delta (#325). (Server, lab2)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

Security data review is clear at exact head 04038271616cc3fbcd37c7ba1b96d5f98e57205d.

• All 11 small-host summaries parse as durable-workflow.server-port-small-host-summary/v1. Driver and target identities in every file bind the exact rc.3 profile SHA-256 520f4157ffc3e4118cc3fc0df58151c07292d3dede4228a35569743e6fda592d.
• Every native run names the published rc.3 index sha256:899b404b…; every PHP run names final PHP Server 2.11.8 sha256:3848d5d5…. No source/profile pin is silently transferred.
• Every summary records clock.cross_host_timing_reliable=false, zero OOM kills, only restarts=0 oom=false container states, and containers=0 volumes=0 teardown. The note therefore correctly excludes cross-host latency claims while retaining the explicit 2-second capacity bound and resource measurements.
• The capacity table matches the summaries exactly: AMD 1 GiB 4 / 8 / none, AMD 2 GiB 4 / 4 / none, vc2 reruns 1 / 2 / none. The stated AMD rate-1 CPU comparisons also match the rc.3 and retained rc.2 summaries (0.099/0.096 Server, 0.183/0.180 MySQL, 0.0802/0.0795 SQLite); the rate-2 values remain within a few percent.
• The vc2 rerun files support the lower-ceiling explanation without turning it into a portable capacity claim: MySQL 2/s closes 39/120 and 49/120 at 1.0–1.2% steal; SQLite 4/s closes 237/240 but fails the late-offer/pending-work probe at 2.4–3.4% steal. The unchanged MySQL image and Server both consume more CPU on that saturated instance, while the AMD plans do not reproduce a per-workflow regression.
• The matched-4c tables support the quoted latency, CPU and memory ranges and the more cautious conclusion that the earlier PHP collapse was not reproduced and remains unconfirmed. The public delta contains no literal endpoint/address or raw result directory.

This is data-only clearance. Ordinary exact-head checks remain the merge prerequisite. Carrying the rc.3 performance evidence to rc.4/final is consistent with the already recorded source boundary: their only runtime delta is #939 schedule next-fire math, which this workload does not exercise.