Update threading performance report with reproduced numbers

The previous report claimed 1.0M req/s at 740ns serial CPU work for the /ok health check endpoint. That measurement was made with an earlier design that transferred unique ownership of connections through the pipeline.

The current server-owned connection model adds per-request synchronization overhead (mutex + WeakRef + pending response queue) that lowers the raw /ok throughput. Reproducing on an AMD Ryzen 9 7900 with the current Release build gives approximately 825k sustained req/s with the same 740ns serial CPU work.

Updated the report to reflect the reproduced numbers and added a note explaining the historical context and why the ownership model changed (to support streaming endpoints like /v1/subscribe and safer async responses).

threading_performance_report.md

@@ -2,15 +2,17 @@
 
 ## Summary
 
-WeaselDB's /ok health check endpoint achieves 1M requests/second with 740ns of configurable CPU work per request through the 4-stage commit pipeline, while maintaining 0% CPU usage when idle. The configurable CPU work serves both as a health check (validating the full pipeline) and as a benchmarking tool for measuring per-request processing capacity.
+WeaselDB's /ok health check endpoint achieves approximately 825k requests/second with 740ns of configurable CPU work per request through the 4-stage commit pipeline, while maintaining 0% CPU usage when idle. The configurable CPU work serves both as a health check (validating the full pipeline) and as a benchmarking tool for measuring per-request processing capacity.
+
+> **Note on historical numbers**: An earlier version of this report claimed 1.0M requests/second at 740ns serial CPU work. That measurement was made using a design that transferred unique ownership of connections through the pipeline. The current server-owned connection model adds per-request synchronization overhead that lowers the raw /ok throughput, but enables streaming endpoints such as `/v1/subscribe` and safer async response handling.
 
 ## Performance Metrics
 
 ### Throughput
 
-- **1.0M requests/second** /ok health check endpoint (4-stage commit pipeline)
+- **~825k requests/second** /ok health check endpoint (4-stage commit pipeline)
 - 8 I/O threads with 8 epoll instances
-- Load tester used 12 network threads
+- Load tester used 10 network threads
 - **0% CPU usage when idle** (optimized futex wake implementation)
 
 ### Threading Architecture
@@ -24,10 +26,10 @@ WeaselDB's /ok health check endpoint achieves 1M requests/second with 740ns of c
 
 **Health Check Pipeline (/ok endpoint)**:
 
-- **Throughput**: 1.0M requests/second
+- **Throughput**: ~825k requests/second (sustained over a 30-second run)
 - **Configurable CPU work**: 740ns (4000 iterations, validated with nanobench)
-- **Theoretical maximum CPU time**: 1000ns (1,000,000,000ns ÷ 1,000,000 req/s)
+- **Theoretical maximum CPU time at this throughput**: ~1212ns (1,000,000,000ns ÷ 825,000 req/s)
-- **CPU work efficiency**: 74% (740ns ÷ 1000ns)
+- **CPU work efficiency**: ~61% (740ns ÷ 1212ns)
 - **Pipeline stages**: Sequence (noop) → Resolve (CPU work) → Persist (response) → Release (cleanup)
 - **CPU usage when idle**: 0%
 
@@ -76,7 +78,7 @@ I/O Threads (8) → HttpHandler::on_batch_complete() → Commit Pipeline
 
 - Server: test_benchmark_config.toml with 8 io_threads, 8 epoll_instances
 - Configuration: `ok_resolve_iterations = 4000` (740ns CPU work)
-- Load tester: targeting /ok endpoint
+- Load tester: targeting /ok endpoint, 10 network threads, 8 connect threads, 2000 concurrent connections, 500 requests per connection
 - Benchmark validation: ./bench_cpu_work 4000
-- Build: ninja
+- Build: ninja Release
 - Command: ./weaseldb --config test_benchmark_config.toml