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.
30k-45k req/s/core is the measured range in bench/RPS (cold-SQLite
floor to LRU-cached hot-set ceiling). No inline caveats here on
purpose -- anyone who wants the fine print goes and reads the harness.
AssetStoreServer runs on a single dedicated smarm actor thread, so a
plain HashMap+VecDeque LRU in front of the SQLite lookup needs no
locking. Capacity configurable via CCC_CACHE_CAPACITY (default 256).
Bench (bench/RPS): +42-47% RPS under a cache-sized/hot-set workload,
but a small net loss under adversarial uniform-random access with a
cache smaller than the catalog. Real traffic is hot-set skewed, so
net win in practice; capacity should be tuned to the expected hot set.
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
distroless has no shell, so managing packages against a running
container means exec-ing the ccc binary directly. Files being added
need to exist inside the container already, so bind-mount a host
./staging dir to /staging for that.
- docker-compose.yml: mount ./staging:/staging alongside the data volume
- README: document docker compose exec + staging workflow
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