.gitbay/wiki/Performance.org

 1#+title: Performance
 2
 3Results from a stress test of gitbay.org (2026-08-25): a server-side
 4import of the Git project's own repository — 82,056 commits, 1,016
 5refs, 167MB packed — followed by timed requests against every page
 6type. The instance is a single 1 vCPU / 1GB VPS that was concurrently
 7running the CI runner, the mirror worker, and the scheduler.
 8
 9* Summary
10
11The import took 41.5 seconds end to end. Every core page rendered in
12under a second against the full history; the heaviest operations —
13blame on a 7,000-line file and full-clone pack generation — cost what
14git itself costs, and nothing else. Load peaked at 0.42 and memory
15held near 190MB through the entire run. A full anonymous HTTPS clone
16of all 82,056 commits completed in 17 seconds and round-tripped with
17an identical commit count.
18
19* Numbers
20
21| operation                                      |  time |
22|------------------------------------------------+-------|
23| server-side import (=repo import=)             | 41.5s |
24| repo tree + README render                      | 0.56s |
25| log page (50 commits, signature checks)        | 0.68s |
26| per-file history (=?path=diff.c=)              | 0.61s |
27| directory history (=?path=Documentation=)      | 0.55s |
28| refs page (1,016 refs)                         | 0.61s |
29| blob of diff.c (7k lines, 3MB highlighted)     | 1.57s |
30| blame on diff.c across the full history        | 2.20s |
31| content grep                                   | 0.70s |
32| archive tar.gz (12MB)                          | 2.46s |
33| signed-tag commit page (unknown-key path)      | 0.29s |
34| shallow HTTPS clone                            |  3.8s |
35| full HTTPS clone (82,056 commits)              | 17.2s |
36
37* Why it holds
38
39gitbay keeps no object database of its own: transports stream through
40=git upload-pack=, object reads go through =git cat-file --batch=, and
41blame, grep, and archives are the git binary doing what it already does
42well. The forge's own work — auth, policy, rendering — is milliseconds
43around that. Metadata lives in one SQLite file in WAL mode, which at
44this scale never appears in a profile.
45
46The practical ceiling on this hardware is concurrent pack generation:
47full clones of large repositories are CPU-bound in git itself (the 17s
48clone ran git at ~156% CPU). =limits.pack_concurrency= bounds how many
49run at once across SSH, HTTP and git://, with a queue behind it (see
50[[Admin]], =[limits]=); the measurements below set its default.
51
52* Concurrent clones
53
54Measured with =deploy/clonebench.sh https://gitbay.org/krz/gitbay.git <n>=
55from a machine outside bay1 (four cores), before and after the pack
56limit was deployed with its defaults (=pack_concurrency= 3,
57=pack_per_principal= 2, =pack_queue= 32, =pack_queue_wait= 60s). All
58clones in one run come from one address, so the per-principal cap
59applies to them; the "limit off" run sets the counts to -1.