Real-world crawl benchmark against live en.wikipedia.org. Last run: 2026-06-29 · 100 pages · concurrency 8 · Apple M1.
What this measures
- Class:
crawler-runtime— network → HTML parse → DOM extract - Mode:
extract(title + wiki links viaquerySelector) - Koko: 8×
koko serve(multi-process) - Chromium: 8 tabs, 1 browser (multi-tab-single-process)
Architecture note
Peak process count and peak RSS are not apples-to-apples across architectures. Use RSS/page, sessions/GB, and CPU-sec/page for cost comparisons.
Scalability comparison
| Metric | Koko | Chromium | Ratio (V/C) |
|---|---|---|---|
| Wall time | 8911 ms | 11965 ms | 0.74× |
| Throughput | 11.22 p/s | 8.36 p/s | 1.34× |
| Mean latency | 648.0 ms | 829.4 ms | 0.78× |
| TTFX mean | 648.0 ms | 751.8 ms | 0.86× |
| Peak RSS | 852.8 MiB | 2988.0 MiB | 0.29× |
| RSS / page | 8.5 MiB | 29.9 MiB | 0.29× |
| Sessions / GB | 9 | 2 | 4.50× |
| CPU-sec / page | 0.0883 | 0.1510 | 0.58× |
| Success rate | 100/100 | 100/100 | — |
Cost & density takeaways
- Memory: Koko peak RSS ~3× lower — better footprint per crawl worker
- Agent density: ~9 concurrent sessions per GB RAM vs Chromium ~2
- CPU cost: 0.088 vs 0.151 CPU-sec/page
- TTFX: Koko reaches first extractable element faster
Limitations
Wikipedia articles are mostly static HTML. This workload does not stress WebGL, SPA routing, React hydration, service workers, or bot detection.