# Performance and resilience — 2026-10-27

These are bounded local synthetic measurements, not production capacity or a model benchmark. CPU/GPU/server assumptions from the original task were not re-probed on production.

Thirty-six real sequential PDF/DOCX parser children (`structural-extraction-01/resources.json`) completed. Wall time median **2.335s**, maximum **5.653s**; CPU median **1.930s**, maximum **3.813s**. Peak Windows working set median **142,776,320 bytes**, maximum **146,653,184 bytes**. Inputs totalled **1,058,593 bytes**, structured outputs **31,664 bytes**. Working-set observations do not establish Windows kernel memory enforcement. Output bytes do not measure peak temporary disk allocation.

The current C# harness records interpretation-call timings separately in each structural metric case. PDF median **0.854ms**, maximum **65.587ms**; DOCX median **0.554ms**, maximum **67.034ms** (18 cases each). These include process/JIT effects and are not parser conversion times. Upload validation, normalization/validation and review preparation do not have independently qualified span timings; browser upload-to-ready includes those stages. No invented per-stage latency or percentile is supplied.

`sidecar-load-01/results.json` records two simultaneous requests to the owned loopback read-only test container, with a 1 GiB memory/two CPU/128 PID/512 MiB tmpfs limit. The admitted DOCX returned 200 with 13 blocks in **2.921s**. The concurrent request returned 503 busy in **0.109s**, demonstrating the one-child bound. Before and after, `/tmp` reported zero KiB and zero `work-*` directories. Post-run container memory was 356.8 MiB; this is a snapshot, not peak memory. No sustained stress, production saturation or denial-of-service test was run.

Real-browser attachments and `journey-latencies.json` retain actual sampled persisted stages and per-journey timing. The four first uploads reached pending review in **1,983–3,024ms**; approved application through independent durable readback took **173–198ms**; editor open/edit-to-preview **2,584–2,799ms**; PDF export-to-saved-bytes **1,122–1,264ms**. These browser cases use the isolated application test database and real sidecar; they are not MariaDB latency benchmarks. Reconfirmed target application took 133ms; exact-source replay/readback 178ms. User review time includes automation and is not human correction burden. Database transaction correctness is tested separately with finite MariaDB concurrency barriers and rollback injection; no production outage or storage power-loss experiment was run. Parser timeouts and malformed inputs are covered separately by the Python tests; no fabricated timer marks a job complete.

Limits remain the existing upload/page/archive/text caps, one parser child, bounded subprocess deadline/CPU/POSIX memory and backend operation admission/recovery. Cancellation and terminal-state protection prevent stale retry/retention from reopening accepted or discarded runs. Future capacity qualification should use an approved isolated host representative of production, sustained bounded mixed-document queues, peak CPU/RSS/tmpfs sampling, cancellation/restart/outage recovery and database latency percentiles. Real model timings remain **BLOCKED** until immutable-artifact qualification.

The final real MariaDB80-case run records one warmed reviewed-application sample of **51.055ms**, including validation, merge, transaction and Identity projection (`ReviewedImportApplyMs` in `mariadb-final-01/mariadb.trx`). The new actual connection-loss test confirms rollback and exact retry/replay rather than a timeout being treated as recovery. The long real-Docling/browser fixture completes in **33.4s** for source upload, explicit fixture approval/readback and three complete PDF exports; this is an automated task duration, not measured human effort. All three exports contain four pages and all expected facts/associations; no live model or production load was involved.