116 lines
6.3 KiB
Markdown
116 lines
6.3 KiB
Markdown
# RustProxy 0.33.8 verification report
|
|
|
|
This report accompanies the performance and compatibility work on the supplied
|
|
0.33.7 source archive and executable. All measurements use disposable local
|
|
state. Production data, certificates, configuration and installed services are
|
|
not modified. Raw results and exact binary hashes are supplied in the separate
|
|
verification archive. The live runners are in `scripts/performance/`.
|
|
|
|
## Scope and acceptance
|
|
|
|
The target is reduced work per uncached reverse-proxy request and per local
|
|
static-file response while retaining routing, security, cache policy, streaming,
|
|
observability and administrative functionality. The LB panel, database schema,
|
|
default TLS policy, cache defaults and bounded connection recycling are unchanged.
|
|
The performance comparison requires the same compiler, locked dependencies,
|
|
release profile, CPU allocation, payloads and client configuration for the
|
|
unmodified source and the candidate. The supplied executable is also retained as
|
|
an independent compatibility baseline.
|
|
|
|
Acceptance has separate layers: compilation and Rust tests; source/SQL/upgrade
|
|
checks; actual HTTP process tests; actual TLS/H2/H3/WebSocket tests; repeated
|
|
before/after/nginx throughput measurements; and a bounded mixed-traffic soak.
|
|
A passing source assertion or simulated DOM check is not a live runtime result.
|
|
Passing this matrix is not a claim that every possible deployment is covered.
|
|
|
|
## Baseline findings
|
|
|
|
The first candidate Rust run completed 658 tests successfully, with 22 failures
|
|
and one explicitly ignored formatting microbenchmark. An unmodified-source run
|
|
reproduces the old failures; the audit records each stale fixture and each actual
|
|
defect separately. The raw initial failed runs remain in the evidence archive.
|
|
Tests that expected obsolete behavior are corrected to exercise the currently
|
|
documented contract; security, cache invalidation and transport guarantees are
|
|
not weakened to obtain a passing result.
|
|
|
|
The initial live HTTP matrix gave identical results for the supplied executable
|
|
and rebuilt 0.33.7: 145 passes, three failures and one skipped optional Brotli
|
|
decoder case. All three failures concerned local HTTP/1 file-body completion:
|
|
normal responses were recorded as cancelled, and full or empty files failed to
|
|
publish a cache entry. The candidate uses a bounded local-file body with accurate
|
|
end-of-stream reporting. Arbitrary upstream bodies retain their original trailer
|
|
and end-of-stream handling.
|
|
|
|
The supplied executable passed 111 actual transport assertions covering verified
|
|
TLS, H2, H3/QUIC, stream multiplexing, uploads, cache behavior, ranges, validators
|
|
and HTTP/1 WebSocket data/control frames. The same runner is used for the final
|
|
candidate. The H3 client adapter accounts for HEAD semantics without disabling
|
|
GET body-length validation.
|
|
|
|
## Compatibility checks
|
|
|
|
The Rust suites exercise cache privacy, Vary and scheme separation, publication
|
|
generation barriers, stale access rules, disk tiers, header policies, ACL and
|
|
SSRF decision paths, timeout and permit lifetime, actual codecs, filesystem
|
|
bounds, symlink policies, range/conditional handling, SQL-backed administration,
|
|
TLS configuration, loopback upstream H1/H2 and raw H2 listener behavior. Stream
|
|
tests include real TCP/UDP peers. PHP tests use a deterministic FastCGI protocol
|
|
peer rather than an installed PHP-FPM application.
|
|
|
|
The HTTP process runner checks exact response bytes and hashes, streaming before
|
|
the final upload chunk, non-replayable POST failures, client cancellation,
|
|
configuration reloads, scoped headers and security policy, administration
|
|
session/CSRF, cache OFF/ON and privacy behavior, compression and transformations.
|
|
The transport runner uses actual local TLS and QUIC connections and trusts the
|
|
fixture certificate explicitly.
|
|
|
|
History-specific tests retain exact log fields, bounded chronological retention,
|
|
drop accounting and delivery to live subscribers and configured sinks during
|
|
forced history-lock contention. Cloning and destruction of evicted entries occur
|
|
outside the history mutex. This preserves the existing best-effort policy;
|
|
saturation measurements must still disclose actual history drops.
|
|
|
|
SQL checks apply all ten migrations twice, exercise named dashboard presets and
|
|
account isolation, and verify the 16-preset bound and cascade behavior. The source
|
|
upgrade test uses disposable installations to check the stopped-process guard,
|
|
held lock rejection, data/configuration preservation, managed source replacement,
|
|
backup creation and symlink rejection. Existing JavaScript checks retain their
|
|
status as simulated UI checks; no browser acceptance is inferred from them.
|
|
|
|
## Reproduction
|
|
|
|
Use the project entry points, which set the private process umask required by
|
|
key-store and certificate fixtures:
|
|
|
|
```bash
|
|
./dev.sh check
|
|
CARGO_INCREMENTAL=0 ./dev.sh test
|
|
python3 scripts/tests/dashboard_presets_sql_test.py
|
|
python3 scripts/tests/upgrade_performance_test.py
|
|
```
|
|
|
|
The isolated validation environment uses Rust 1.99.1 with the original locked
|
|
dependency versions, nginx 1.26.3 and wrk 4.2.0. See
|
|
`scripts/performance/README.md` for live regression, transport, profiling,
|
|
benchmark and soak commands. Supply explicit executable paths and new output
|
|
directories; preserve failed runs as evidence.
|
|
|
|
## Measurement boundaries
|
|
|
|
Throughput measurements use HTTP/1.1 keep-alive, cache OFF, identity encoding,
|
|
1040-byte, 64-KiB and 1-MiB objects, separate server/origin/client CPU sets,
|
|
interleaved variants and excluded warm-up. Resource samples retain CPU time,
|
|
RSS, file descriptors, generator errors and application drop counters. Medians
|
|
use all scheduled repetitions. Closed-loop wrk latency is not an open-loop SLA.
|
|
Syscall profiles are collected separately from timed throughput runs.
|
|
|
|
Remaining deployment-specific checks include a 24-hour production-like soak,
|
|
remote-network latency and loss, actual PHP-FPM applications, external Tinyauth,
|
|
DNS rebinding against a real resolver, and HTTP/2 or HTTP/3 WebSocket tunnels.
|
|
The measured same-host comparison does not establish internet-facing capacity.
|
|
|
|
Final executable-specific outcomes, run counts, percentages and resource costs
|
|
are recorded in the separately generated performance/evidence report after the
|
|
release build. This embedded document describes the test contract and baseline;
|
|
it does not substitute planned work for a completed measurement.
|