benchmarks
O limite de cache de 10 GB é o verdadeiro gargalo do CI
Instrumentamos 40.000 execuções de fluxo de trabalho. O comportamento do cache previu o tempo do relógio melhor do que a contagem de vCPU, e a maioria das equipes ultrapassa o limite sem nem perceber.
{autor} · {papel} · {data} · {minutos} {minutosLabel}
Existe um modo de falha nas GitHub Actions que não produz nenhum erro, nenhum aviso e nenhuma linha de log. Seu repositório ultrapassa 10 GB de cache, as entradas usadas menos recentemente começam a ser removidas e, a partir desse dia, uma fração de suas execuções começa silenciosamente.
Ninguém é avisado por isso. A construção ainda passa. É apenas mais lento, para sempre, e quando alguém investiga a mudança já tem seis meses.
O que medimos
Em 40.000 execuções em repositórios que aceitaram, registramos a taxa de acertos do cache, a duração da restauração, o tamanho do executor e o tempo total do relógio. Duas coisas se destacaram.
A segunda descoberta é a mais acionável: abaixo de aproximadamente 80% da taxa de acerto do cache, a adição de vCPUs quase não alterou o tempo total do pipeline. As equipes estavam comprando máquinas maiores para compensar os caches frios, o que é quase a forma mais cara de resolver esse problema.
A velocidade de restauração é tão importante quanto a taxa de acerto
Um cache que leva quatro minutos para ser restaurado e economiza três minutos de trabalho é uma perda líquida e reportará uma taxa de acerto de 100% enquanto você perde tempo. Vimos vários repositórios exatamente neste estado.
O que fazer sobre isso
Seu próximo build pode ser duas vezes mais rápido, pela metade do preço
Comece grátis. Sair é a mesma linha, e publicamos esse diff também.