Summary
stable-mirror.omarchy.org sits behind Cloudflare, but every response comes back cf-cache-status: DYNAMIC — the edge never caches, so each package proxies back to origin. From Taipei this means low latency (<300ms TTFB, I'm hitting the local TPE edge) but poor sustained throughput (~140 KB/s), because the bottleneck is the origin link rather than the nearby edge. A full update pulling a few hundred MB takes 30–40+ minutes.
Measurements (from Taipei, Taiwan)
| File |
Size |
Total time |
Throughput |
TTFB |
cf-cache-status |
extra/os/x86_64/extra.db |
8.7 MB |
61 s |
~142 KB/s |
0.30 s |
DYNAMIC |
core/os/x86_64/core.db |
~127 KB |
0.6–2.7 s |
48–200 KB/s (erratic) |
0.02–0.27 s |
DYNAMIC |
Edge: cf-ray: ...-TPE, edge IP 104.18.2.204. TTFB is consistently good, so distance/edge isn't the issue — throughput to origin is.
Root cause
Responses carry no Cache-Control header (only Last-Modified):
content-length: 8724890
last-modified: Mon, 20 Jul 2026 23:23:00 GMT
cf-cache-status: DYNAMIC
With no Cache-Control, Cloudflare doesn't cache these by default → DYNAMIC on every request.
Suggested fix
Package repo files are effectively immutable (versioned filenames), so they're ideal to cache at the edge:
- Set a Cloudflare Cache Rule (or origin
Cache-Control: public, max-age=...) to cache *.pkg.tar.zst (and the *.db with a shorter TTL / revalidation).
- Optionally set
Edge Cache TTL and enable "cache everything" for the repo path.
Once files serve from the edge, Asia (and any region far from origin) would get near-line-rate downloads instead of origin-throttled ~140 KB/s.
Happy to re-run measurements after a change to confirm.
Summary
stable-mirror.omarchy.orgsits behind Cloudflare, but every response comes backcf-cache-status: DYNAMIC— the edge never caches, so each package proxies back to origin. From Taipei this means low latency (<300ms TTFB, I'm hitting the local TPE edge) but poor sustained throughput (~140 KB/s), because the bottleneck is the origin link rather than the nearby edge. A full update pulling a few hundred MB takes 30–40+ minutes.Measurements (from Taipei, Taiwan)
extra/os/x86_64/extra.dbcore/os/x86_64/core.dbEdge:
cf-ray: ...-TPE, edge IP104.18.2.204. TTFB is consistently good, so distance/edge isn't the issue — throughput to origin is.Root cause
Responses carry no
Cache-Controlheader (onlyLast-Modified):With no
Cache-Control, Cloudflare doesn't cache these by default →DYNAMICon every request.Suggested fix
Package repo files are effectively immutable (versioned filenames), so they're ideal to cache at the edge:
Cache-Control: public, max-age=...) to cache*.pkg.tar.zst(and the*.dbwith a shorter TTL / revalidation).Edge Cache TTLand enable "cache everything" for the repo path.Once files serve from the edge, Asia (and any region far from origin) would get near-line-rate downloads instead of origin-throttled ~140 KB/s.
Happy to re-run measurements after a change to confirm.