A local cache for repositories kept in GCS (or S3): pages on them take seconds issue #234 closed: completed andymccall opened this · 1 comment
andymccall set labels performance ·
referenced by 2 changes on 17 Oct 2026
andymccall
Done: ranges and sizes of large objects are kept on the data disk beside whole small objects (oxygen 24f95a3e), and packed objects no longer cost a bucket miss each (b2952b8d). See issue #228 for the numbers.
andymccall closed ·
Andy, 2026-10-16: doomsdayone/metalgear2 keeps its data in a GCS bucket; negotiate takes about 8 s, a proposal page about 30 s, the proposals API 12-30 s, the hub holds about 7 GB. Objects are content-addressed and never change, so a read-through disk cache can keep them for ever: a size cap with LRU eviction, filled on read and on push (write-through), optionally warmed when the hub starts (pre-cache, Andy's idea), with hit/miss counts. Likely most of issue #228.