techniek
Het bouwen van een CI-cache die niet beperkt wordt
Hoe we cacheherstel met 1 GB/s uitvoeren, en waarom bandbreedte belangrijker is dan capaciteit.
{auteur} · {rol} · {datum} · {minuten} min leestijd
Cachediscussies richten zich op de capaciteit: de limiet van 10 GB, het uitzettingsbeleid en het aantal treffers. In de praktijk is bandbreedte de beperking die mensen voelen en zelden benoemen.
Waarom herstelsnelheid domineert
Een cache-item helpt alleen als het herstellen ervan sneller gaat dan het opnieuw maken ervan. Bij een overdrachtssnelheid die laag genoeg is, wordt elke cache een nettoverlies en zal deze de hele tijd een perfect hitpercentage rapporteren.
Wat we hebben gebouwd
- Cache opgeslagen op NVMe in dezelfde beschikbaarheidszone als de runnerpool
- Inhoud-geadresseerde brokken, zodat ongewijzigde delen niet opnieuw worden overgedragen
- zstd-compressie, gekozen voor decompressiesnelheid in plaats van verhouding
- Parallelle chunk-fetch die de link verzadigt in plaats van een enkele stream
Het resultaat is een aanhoudend herstel van ongeveer 1 GB/s. Dat verandert welke dingen überhaupt de moeite waard zijn om te cachen - in dat tempo wordt het cachen van een toolchain-directory van 6 GB duidelijk correct in plaats van marginaal.
Je volgende build kan twee keer zo snel zijn, voor de halve prijs
Begin gratis. Weggaan is dezelfde ene regel, en die diff publiceren we ook.