docs: add Phase 19 performance baselines and capacity analysis#341
Conversation
Captures SDK E2E (83/83 pass) and load test results comparing someguy sidecar vs delegated-ipfs.dev vs Phase 18 Kubo-direct baselines. Key findings: - 12x throughput improvement over Phase 18 (1.25 → 15.28 ops/s) - Error rate eliminated (4.6% → 0%) - Warm DHT someguy beats delegated-ipfs.dev by ~40-50% on median latency Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: d80496e88078
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 04750e4993a4
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 05da4f1ecc5f
Mixed workload scaling results from staging: - Near-linear throughput scaling (2.7x at 3x clients) - Zero errors at all concurrency levels - p50 latency grows only 15-25% from 10→30 clients - Staging VPS not yet saturated at 30 concurrent clients Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: d2dd8f4fd7cf
- 100 clients: 24.05 ops/s, 0 errors, uploadFile p50=5.1s - Prometheus analysis: Kubo IPFS pinning is 95% of upload latency - Each uploadFile = 3 sequential pins (~1.7s each) + 2 IPNS publishes (~130ms each) - IPNS publish is fast (DB upsert only), DHT propagation is async - 50/75 client runs queued to fill scaling curve Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 062f9488e089
- Complete scaling curve: 10/20/30/50/75/100 clients - Throughput plateaus at ~23-24 ops/s from 50→100 clients - Knee at ~50 clients where Kubo pin concurrency saturates - Updated Prometheus metrics with full cumulative counts (152K pins) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 4330f08634f2
- 200 clients: 28.50 ops/s, 4 errors (0.05%), uploadFile p50=8.8s - First errors appear at 200 clients — error-free up to 100 - Throughput plateau confirmed: 23-28 ops/s from 50→200 clients - Kubo pin mean stays flat at ~1.56s — client latency increase is from queuing, not Kubo degradation - 1 IPNS 409 conflict at 200 clients (expected seq collision) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 213de760f59e
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughPhase 19 performance baseline documentation updated with extended load test results for mixed workload scaling (10–200 clients), including throughput and latency metrics, along with server-side latency breakdown from Prometheus showing sequential API call attribution. Instructions for additional k6 load tests replaced with newly documented scaling and latency data. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Keep extended load test data (10–200 clients), upload flow breakdown, and Prometheus analysis from branch. Remove completed "Run k6 load tests" comparison target from main (now done). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 441c9b591b20
Summary
19-someguy-ipns-baselines.md)Key findings
Other changes
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit