Instrument the four suspect regions from bench/RPS: cache-lookup, cache-insert, sqlite-query, and gzip-decode, plus an asset-served progress point. New `ccc causal` subcommand runs the sweep against live traffic and prints a summary (optionally a .coz file and a ledger audit). Ran it under the same 80/20 hot-set workload as bench/RPS - see bench/CAUSAL.md for the methodology and results. Findings: - sqlite-query is the real bottleneck on a cache miss (+20.5% at a 50% speedup, roughly linear). - cache-lookup/cache-insert are noise-level (0-4%) - the O(n) recency-scan touch() bench/RPS flagged as a possible follow-up is not actually costing anything, so that's off the table. - Switched prepare() -> prepare_cached() on the query as the obvious fix; re-measured and it made no real difference (+20.0% -> +20.5%, within noise). Kept it anyway (strictly not worse), but it shows execution cost (B-tree lookup + BLOB copy) dominates over parse cost in that site. - gzip-decode barely gets exercised since real clients (and oha) negotiate gzip - not worth optimizing further. - Net conclusion: the existing CCC_CACHE_CAPACITY tuning from bench/RPS (+42-47% RPS) is the correct lever, and causal profiling explains why - every cache hit skips the one site that matters. Zero cost when the feature is off: causal_site!/progress! compile to no-ops without smarm-causal.
41 lines
1.1 KiB
Markdown
41 lines
1.1 KiB
Markdown
# C3 - Cached Content Conduit
|
|
|
|
My super simple CDN built for distributing my own (text) content.
|
|
|
|
Pushes 30k-45k requests/sec per core for a realistic workload -- see
|
|
[bench/RPS](bench/RPS) if you want the receipts, and
|
|
[bench/CAUSAL.md](bench/CAUSAL.md) for causal-profiling which sites
|
|
actually matter (`cargo build --features causal`).
|
|
|
|
## Running in Docker
|
|
|
|
```
|
|
docker compose up -d
|
|
```
|
|
|
|
The runtime image is `distroless` (no shell, no package manager, ~24MB),
|
|
so managing packages happens via `docker exec` running the `ccc` binary
|
|
directly rather than an interactive shell:
|
|
|
|
```
|
|
docker compose exec ccc /usr/local/bin/ccc create demo
|
|
```
|
|
|
|
To add a file, it needs to exist inside the container first. Drop it in
|
|
the `./staging` dir, which is bind-mounted to `/staging`:
|
|
|
|
```
|
|
cp app.js staging/
|
|
docker compose exec ccc /usr/local/bin/ccc add demo /staging/app.js 1.0.0
|
|
```
|
|
|
|
(Alternatively `docker cp` a file straight into the container if you'd
|
|
rather not use the staging mount.)
|
|
|
|
## License
|
|
|
|
AGPL-3.0-only - see [LICENSE](LICENSE). If you run a modified version
|
|
of this as a network service, you must make the modified source
|
|
available to its users.
|
|
|