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.
- Bump urus to v0.2.2 (v0.2.1 -> v0.2.2) and smarm to v0.6.0, pulling in
a urus fix (pushed alongside this commit) that spawns per-connection
actors with a 256 KiB stack via smarm's RFC 019 SpawnOpts instead of
the runtime's bare 64 KiB default. Without it, any request that hit
fetch_asset_handler's in-handler gzip decompression (i.e. any client
not sending Accept-Encoding: gzip) blew the actor's guard page and the
connection died with no response - reproduced 5/5 runs before the fix,
0/5 after.
- Add `ccc stats`: active/archived package and version counts, total
gzipped bytes stored, and the resolved db path. Useful for a quick
sanity check before/after a deploy.
- Add a real test suite, which is what caught the crash above:
- src/store.rs unit tests: schema init/idempotency, create/add/
archive success and error paths, gzip round-trip, upsert
semantics, stats aggregation.
- tests/cli.rs: black-box tests against the compiled `ccc` binary
covering usage/exit codes and the full create/add/archive/stats
lifecycle.
- tests/server.rs: boots `ccc serve` as a real subprocess and drives
it over raw TCP (no HTTP client dependency) - boot-without-
crashing, asset serving both compressed and decompressed, 404s,
package listing incl. archived-package hiding, and repeated
sequential requests against one long-lived process.
27/27 tests passing (12 unit + 9 CLI + 6 server).
Ensures anyone running a modified version of C3 as a network service
has to share their changes back, not just users who redistribute the
binary.
- LICENSE: full AGPLv3 text with copyright notice filled in
- Cargo.toml: license = "AGPL-3.0-only"
- README: brief license section
A minimal CDN for serving versioned, gzip-compressed static assets,
backed by SQLite and an actor-based (smarm) storage server, with
HTTP serving via urus.
- CLI: create/add/archive packages and versions, serve over HTTP
- Storage: SQLite-backed asset store (src/store.rs) with gzip
compression on ingest and content-type sniffing by extension
- HTTP: GET /packages (list packages+versions), GET
/assets/:package/:version/:filename (serves gzip or transparently
decompressed, with immutable long-lived cache headers)
Markk116