claudetools/.claude/memory/reference_gitea_git_op_latency.md

name, description, metadata

name	description	metadata
reference_gitea_git_op_latency	Gitea git-op latency benchmarks - SSH is SLOWER than internal HTTP+token; the SOPS credential lookup is only ~0.33s, not the bottleneck. Do not switch to SSH for speed.	type reference

Benchmarked 2026-06-01 on GURU-5070 (ls-remote HEAD, claudetools repo):

Path	Time
SOPS decrypt of Gitea token (vault.sh get-field services/gitea.sops.yaml credentials.api.api-token)	~0.33s
Internal HTTP+token http://...@172.16.3.20:3000	~0.55s
External HTTPS git.azcomputerguru.com (Cox/NPM/Cloudflare)	~0.83s
SSH passwordless git@172.16.3.20:2222	~1.5s (SLOWEST)

Takeaways:

• The "credential lookup" is only ~0.33s - NOT the cause of slow git ops. Do NOT switch git transport to SSH expecting a speedup; the SSH handshake to :2222 costs more than the SOPS decrypt it saves.
• Gitea built-in SSH server is git@172.16.3.20:2222 (publickey-only). The repo API ssh_url advertises git@172.16.3.21 (port 22) which is WRONG - that's a host sshd (offers password), not Gitea. Gitea SSH_DOMAIN/SSH_PORT config is misconfigured; the real endpoint is .20:2222.
• Switching origin to SSH also breaks sync.sh submodule credential reuse (it derives submodule creds from an embedded-cred HTTP origin URL, ~line 181).
• If repeated 0.33s SOPS decrypts in a session add up, the right optimization is caching the decrypted token (credential helper / session env), NOT changing transport.
• Intermittent real slowness is usually the NPM SSL-renewal reload blips on the EXTERNAL domain - stay on internal 172.16.3.20:3000 (see reference_gitea_internal).
• An SSH key named "GURU-5070" (ed25519) was added to the shared azcomputerguru Gitea account during this test; remove it if the SSH approach is abandoned.