cesnimda
3.9 KiB
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.