.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 defaults (pack_concurrency 3, pack_per_principal 2, pack_queue 32, pack_queue_wait 60s) are set for a four-core host from the single-clone figure above; no concurrent-clone measurement backs them yet. deploy/clonebench.sh <clone-url> <n> starts n full clones at once from a machine other than the server. Anonymous clones together hold at most pack_concurrency − 1 slots, and clones from one address or account count against one principal, so an anonymous run measures those caps rather than the global one. Run it as signed-in clients (SSH keys, or HTTP with bearer tokens) from more than one account, or against an instance with pack_per_principal = -1 and read the result as the anonymous class cap.