Gitfence
Start free

Performance and sizing

Measured on the full Kubernetes history (163,380 commits): one-time setup, clone, fetch and push times, memory, and the host and disk to plan for.

Short answer: Gitfence works on large monorepos. We measured it on the full history of Kubernetes (163,380 commits, 31,600 files) and Terraform (44,774 commits). Day-to-day git is fast: fetches take seconds and pushes about 3 seconds. The slow part happens once: preparing a group's view of the whole history, and each person's first clone.

What was measured

Both repositories were served by a real Gitfence server with a 1.5 GB memory limit, driven with real git over HTTP. Each had a restricted group with realistic rules: three folders hidden and one types-only.

Repository Commits Branches Files Pack size
hashicorp/terraform (Go) 44,774 915 5,606 363 MB
kubernetes/kubernetes (Go) 163,380 62 31,603 1.4 GB

Kubernetes, on 2 vCPUs

Step Time Peak memory
Preparing a group's view (once per set of rules) 33 minutes 992 MB
A person's first clone (772 MB) 7 minutes 992 MB
Fetch after 20 new upstream commits 4.2 seconds 375 MB
Fetch with nothing new 0.3 seconds 372 MB
Push a branch 2.8 seconds 391 MB
Rule change (a hidden folder becomes readable) 2 minutes 1.2 GB
Fetch after the rule change 3 minutes 1.1 GB
A new member's first clone right after a rule change 29 minutes 956 MB

Terraform is smaller: about 4 minutes to prepare a group's view, under a minute for a first clone, and under a second for fetches and pushes.

What the one-time setup means for you

  • Create groups and settle their rules before you invite people. The first person to clone after a group is created, or after its rules change, waits for the preparation.
  • Let the pull request filter finish too. It starts when a group is created or its rules change: 15–25 minutes on a 50,000-commit monorepo. The repository's Pull requests page shows its progress. Until it is ready, contractors' pull requests show "Checking" and their conversations wait.
  • git keeps the connection open while it waits, so the clone finishes in one go. It prints nothing until the preparation ends, which can look like a hang. Clients other than the git command line (JGit, libgit2-based GUIs, go-git) may get "still preparing, run the same command again" instead.
  • On a large repository, creating a group or changing its rules can take minutes. The page may time out while the work finishes on the server; reload it to see the result.

Sizing

Memory goes mostly to git packing a person's view (about 0.7 KB per object in the view's history), plus 0.2 to 0.4 GB for Gitfence. CPUs decide how long a preparation takes (about 5 ms per commit for a Terraform-sized tree, 12 ms for a Kubernetes-sized one), not whether it works.

Repository Host Disk
Up to ~50k commits, ~10k files 2 vCPU, 4 GB the mirror + ~0.4 GB per restricted person
Up to ~150k commits, ~30k files 4 vCPU, 8 GB, 3 GB for Gitfence the mirror + ~1 GB per restricted person + ~1 GB per group
~500k commits, ~100k files 8 vCPU, 16 GB the mirror + 3–4 GB per restricted person

Each restricted person gets their own copy of their view: git would otherwise serve them objects they may not see. To estimate yours before a pilot, run git count-objects -vH and git rev-list --count --all on a fresh clone. On our hosted service we size this with you; self-hosted, see sizing in the install guide.

Not measured yet

  • Go types-only stubs at Kubernetes scale (the runs above hid the types-only folder), and TypeScript-heavy monorepos of that size.
  • Repositories with very large files, and pushes of hundreds of commits.

Next: self-hosting and Types only.

Related guides