Naar inhoud springen

techniek

Wat we hebben geleerd bij het runnen van een miljoen CI-banen

Wachtrijtijd, cachegedrag, juiste grootte en de faalmodi die alleen op schaal voorkomen.

{auteur} · {rol} · {datum} · {minuten} min leestijd

Een miljoen banen is genoeg om de lange staart te zien. Dit is wat ons verraste.

Wachttijd is onzichtbaar en enorm

De stapduur wordt prominent weergegeven. Wachttijd wordt helemaal niet weergegeven. We hebben opslagplaatsen gevonden waar de gemiddelde wachtrijtijd de gemiddelde bouwtijd overschreed, en het team had een kwart besteed aan het optimaliseren van de build.

De meeste hardlopers hebben in beide richtingen de verkeerde maat

Ongeveer 40% van de banen had een gemiddeld CPU-gebruik van minder dan 30%, waarbij werd betaald voor inactieve cores. Nog eens 12% zat gedurende de gehele duur op 100% en bevond zich op het kritieke pad. De juiste maatvoering in beide richtingen was voor de meerderheid van de klanten meer waard dan welke cachewijziging dan ook.

I/O-wacht is de stille moordenaar

npm 40.000 bestanden schrijven, kratten uitpakken, Docker lagen extraheren - het is allemaal geen CPU-werk. Op netwerkgekoppelde opslag domineren deze stappen, en elke CPU-grafiek ziet er prima uit terwijl ze dat doen.

Vlokkige tests kosten meer dan welke modellen dan ook

De directe kosten van een herhaling zijn duidelijk. De indirecte kosten – ingenieurs die echte mislukkingen opnieuw proberen uit te voeren omdat opnieuw proberen de gewoonte is – zijn veel groter en staan ​​op geen enkele factuur vermeld.

Agentverkeer veranderde de vorm van de lading

Opslagplaatsen met AI-codeermiddelen vertonen een pushfrequentie die vele malen hoger is dan opslagplaatsen die alleen voor mensen toegankelijk zijn, in bursts. Het annuleren van gelijktijdigheid ging van een mooie optimalisatie naar een harde vereiste voor deze teams.

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.