Entrar ou criar conta

Upnetix Labs · protocolo de experimento

Protocolo: Qual o impacto do paralelismo de jobs no tempo total de execução de um pipeline CI/CD com GitLab Runner?

Este protocolo mede como diferentes níveis de paralelismo afetam o tempo total de execução de pipelines CI/CD usando GitLab Runner em ambiente controlado. O objetivo é identificar o ponto ótimo de paralelismo antes de saturar recursos e perder eficiência.

Automação de pipelines CI/CD com GitLab Runner do zero à entrega contínua
Ligado ao treinamento Automação de pipelines CI/CD com GitLab Runner do zero à entrega contínua
Protocolo, não resultado. Esta página descreve como medir. Os números que valem são os que você obtém na sua bancada, seguindo o método abaixo. Nenhum valor aqui é resultado de medição da Upnetix.
Pergunta

Como o aumento do paralelismo de jobs em um pipeline CI/CD afeta o tempo total de execução no GitLab Runner?

Hipótese

Aumentar o paralelismo dos jobs reduz o tempo total do pipeline até um limite, após o qual há pouca ou nenhuma melhora devido à saturação de CPU e I/O.

Variáveis

Independentes (o que varia)nível de paralelismo (número de jobs concorrentes configurados no runner)
Dependentes (o que se mede)tempo total de execução do pipeline (segundos)
Controladas (o que fica fixo)hardware do runner (CPU, RAM, disco); versão do GitLab Runner; pipeline YAML idêntico (mesmos jobs, scripts e artefatos); carga do sistema (sem outros processos relevantes); rede local (sem variações de latência ou banda)

Ambiente

Máquina dedicada rodando Linux, com GitLab Runner instalado (versão conforme documentação oficial), pipeline de teste com jobs idênticos (exemplo: uso de sysbench para simular workload CPU-bound), monitoramento de recursos via Prometheus Node Exporter.

Procedimento

  1. Preparação

    Instale o GitLab Runner na máquina dedicada e registre um runner shell.

    consulte a documentação oficial para registro
  2. Configuração

    Configure o arquivo config.toml do runner para o nível de paralelismo desejado (parâmetro concurrent = N).

    sudo nano /etc/gitlab-runner/config.toml
  3. Pipeline

    Crie um pipeline de teste com N jobs idênticos executando sysbench CPU por tempo fixo.

    sysbench cpu --time=30 run
  4. Execução

    Execute o pipeline e registre o tempo total de execução (start/finish no GitLab CI).

  5. Repetição

    Repita para cada valor de paralelismo (exemplo: 1, 2, 4, 8, 16), 5 vezes cada.

  6. Monitoramento

    Colete métricas de uso de CPU e load average via Prometheus durante os testes.

Planilha de coleta

paralelismo_configurado (inteiro)execucao_id (inteiro)tempo_total_pipeline (segundos)cpu_usage_medio (porcentagem)load_average (valor absoluto)
EXEMPLO: 4, 3, 125, 85.2, 4.7

Repetições recomendadas: 5. Baixe a planilha vazia em CSV: colunas prontas.

Análise

Calcule média, mediana e desvio padrão do tempo total para cada nível de paralelismo. Compare os tempos para identificar o ponto de saturação. Analise gráficos de tempo vs. paralelismo e uso de CPU. Interprete onde há ganho real e onde há gargalo.

Critérios de decisão

  • Redução consistente do tempo total até o ponto de saturação
  • Aumento de uso de CPU proporcional ao paralelismo
  • Estabilidade dos resultados entre repetições (desvio padrão baixo)

Fontes de erro e mitigação

  • Variação de carga do sistema: isole o runner
  • Flutuação de rede: use jobs CPU-bound
  • Cache de disco: limpe entre execuções se necessário

Referências

  1. fonte oficial
  2. fonte oficial