.gitbay/wiki/Performance.org

The import took 41.5 seconds end to end. Every core page rendered in under a second against the full history; the heaviest operations — blame on a 7,000-line file and full-clone pack generation — cost what git itself costs, and nothing else. Load peaked at 0.42 and memory held near 190MB through the entire run. A full anonymous HTTPS clone of all 82,056 commits completed in 17 seconds and round-tripped with an identical commit count.

gitbay keeps no object database of its own: transports stream through git upload-pack, object reads go through git cat-file --batch, and blame, grep, and archives are the git binary doing what it already does well. The forge's own work — auth, policy, rendering — is milliseconds around that. Metadata lives in one SQLite file in WAL mode, which at this scale never appears in a profile.

The practical ceiling on this hardware is concurrent pack generation: full clones of large repositories are CPU-bound in git itself (the 17s clone ran git at ~156% CPU). limits.pack_concurrency bounds how many run at once across SSH, HTTP and git://, with a queue behind it (see Admin, [limits]); the measurements below set its default.

Measured with deploy/clonebench.sh https://gitbay.org/krz/gitbay.git <n> from a machine outside bay1 (four cores), before and after the pack limit was deployed with its defaults (pack_concurrency 3, pack_per_principal 2, pack_queue 32, pack_queue_wait 60s). All clones in one run come from one address, so the per-principal cap applies to them; the "limit off" run sets the counts to -1.