Commit 7334280221
Verified · cmc
Layout: unified · split
Home.org +1
| @@ -9,5 +9,6 @@ CLI-first git forge: SSH is the API, the web is a rendering. | ||
| 9 | 9 | - [[API][API and webhooks]] — the JSON API contract, tokens, payloads |
| 10 | 10 | - [[Roadmap][Roadmap]] — status, phases, decisions, what is not planned |
| 11 | 11 | - [[Threat-Model][Threat model]] — what the forge trusts and never does |
| 12 | - [[Performance][Performance]] — stress-test numbers from importing git.git | |
| 12 | 13 | |
| 13 | 14 | This wiki is a git repository: =git clone ssh://git@gitbay.org/krz/gitbay.wiki.git= |
Performance.org added +49
| @@ -0,0 +1,49 @@ | ||
| 1 | #+title: Performance | |
| 2 | ||
| 3 | Results from a stress test of gitbay.org (2026-08-25): a server-side | |
| 4 | import of the Git project's own repository — 82,056 commits, 1,016 | |
| 5 | refs, 167MB packed — followed by timed requests against every page | |
| 6 | type. The instance is a single 1 vCPU / 1GB VPS that was concurrently | |
| 7 | running the CI runner, the mirror worker, and the scheduler. | |
| 8 | ||
| 9 | * Summary | |
| 10 | ||
| 11 | The import took 41.5 seconds end to end. Every core page rendered in | |
| 12 | under a second against the full history; the heaviest operations — | |
| 13 | blame on a 7,000-line file and full-clone pack generation — cost what | |
| 14 | git itself costs, and nothing else. Load peaked at 0.42 and memory | |
| 15 | held near 190MB through the entire run. A full anonymous HTTPS clone | |
| 16 | of all 82,056 commits completed in 17 seconds and round-tripped with | |
| 17 | an 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 | ||
| 39 | gitbay keeps no object database of its own: transports stream through | |
| 40 | =git upload-pack=, object reads go through =git cat-file --batch=, and | |
| 41 | blame, grep, and archives are the git binary doing what it already does | |
| 42 | well. The forge's own work — auth, policy, rendering — is milliseconds | |
| 43 | around that. Metadata lives in one SQLite file in WAL mode, which at | |
| 44 | this scale never appears in a profile. | |
| 45 | ||
| 46 | The practical ceiling on this hardware is concurrent pack generation: | |
| 47 | full clones of large repositories are CPU-bound in git itself (the 17s | |
| 48 | clone ran git at ~156% CPU). A busier instance would scale that with | |
| 49 | cores, not with changes to gitbay. | |