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.
- 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
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
Multi-stage build: rust:1-slim-bookworm to compile (needs a recent
toolchain per smarm/urus's MSRV), then a distroless/cc runtime image
since the binary only links against glibc/libgcc/libm (checked via
ldd) - no shell or package manager needed at runtime, ~27MB vs ~87MB
for a debian-slim runtime.
- CCC_DB_PATH defaults to /data/cdn.db in-container
- docker-compose.yml persists /data in a named volume, maps 8333
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