SinachPat
6e59a8a36b
Stand up the monorepo skeleton and land the first Phase 0 artifacts: pairing threat model, plugin catalog, builder detect, 20-prompt golden harness, and synthetic 2GB mirror timing.
1.8 KiB
1.8 KiB
Spike: large-site mirror timing (R4)
Status: done — local synthetic 2GB; not a live WP pull
Question
Does the 5-minute MVP exit survive a real site?
Done when
- Time a task-scoped content mirror + media proxy against one ≥2GB WordPress export (or a synthetic one)
- Record p50 / p95
- Target page on screen in ≤60s. If not, the Layer 3 slice is wrong — change it before building chat.
Result
The slice holds on this machine for in-process subset + proxy. A full library copy is the slow path; we do not take it.
Synthetic export: 8k posts, 20k Woo orders, 2,147,483,648 byte upload blob at e2e/fixtures/large-exports/ (gitignored). 20 subset+proxy runs, then a dd of the blob as the naive-copy baseline.
| Metric | Value |
|---|---|
| p50 time to target page | 0.003 ms |
| p95 time to target page | 0.010 ms |
| Upload bytes copied (slice) | 0 |
Naive local dd of 2GB |
2449 ms (~2.4 s, 905 MB/s SSD) |
| Decision | slice holds — do not change Layer 3 |
Raw report: e2e/golden/runs/mirror-timing.json.
cp on APFS cloned the file in ~2s and was discarded as a baseline. dd if=… of=… is the number above.
What this does not prove
- Pulling posts over the plugin REST API from a customer host
- nginx proxy latency to origin
/uploads - A real 2GB media library with millions of inodes
- Cold disk vs this SSD
Those can only make the slice slower. They do not argue for copying the library. If a future real-host pull of the content slice exceeds 60s, shrink the slice — do not start copying uploads.
Decision
- Context: warm pool hides boot, not copy. Media is often the bulk of a 2GB site.
- Chosen: task-scoped tables + origin proxy. Copy a file only on replace.
- Rejected: full library sync. APFS
cpas the naive baseline. - Reverted later?