docs: capture todo - Benchmark Płytarium on WinterCMS vs SummerCMS

.planning/todos/pending/2026-10-01-benchmark-the-application-on-wintercms-vs-summercms.md

@@ -0,0 +1,19 @@
+---
+created: 2026-10-01T18:25:06.041Z
+title: Benchmark Płytarium on WinterCMS vs SummerCMS and publish a measured table
+area: docs
+severity: minor
+files:
+  - docs/architecture/performance-and-scaling.md
+---
+
+## Problem
+
+`docs/architecture/performance-and-scaling.md` (quick task 261001-qoa) only gives typical PHP-FPM vs Go ranges, explicitly marked as not measurements of SummerCMS. The user expected a more detailed comparison and wants real numbers from Płytarium, measured on both stacks.
+
+## Solution
+
+1. Baseline now: measure Płytarium on WinterCMS (PHP-FPM, `/media/nvme/dev/golem15/fonoteka`) before the port finishes, so the PHP numbers exist independently of the Go side.
+2. Once its API is ported (Phase 12+), measure Płytarium on SummerCMS (`fonoteka.go`).
+3. Method: record request fixtures with tide (`summer parity:record`), replay them under load with vegeta or k6 against both backends on identical hardware and the same Postgres data. Collect per-route p50/p99 latency, req/s at a fixed concurrency, max sustainable concurrency before p99 degrades, and RSS / total memory (all FPM workers vs one Go process). Group routes by shape (trivial/cached, typical CRUD, DB-heavy).
+4. Add the measured table to the performance page next to the typical-ranges table. Framework docs must not name the application: describe it as "a ported production application" and state the hardware, dataset size and tool versions.