Diagnóstico de Desempenho de Pipeline Meteorológico

Visão Geral

Descubra o estágio que realmente deixa um fluxo de trabalho meteorológico lento antes de otimizá-lo. Meça o caminho de tempo de execução real desde a descoberta da fonte até o artefato final, incluindo dados complementares opcionais e trabalho de fallback.

Esta habilidade diagnostica latência e throughput. Ela não prescreve um provedor de dados, formato de arquivo, decodificador ou otimização específicos.

Quando Usar Esta Habilidade

• Uma busca, sondagem, mapa, animação ou trabalho em lote parece mais lento do que antes.
• Um analisador ou backend nativo é culpado sem evidências de tempo em nível de estágio.
• Execuções locais e executadas em pacotes ou hospedadas têm desempenho diferente.
• Um cache, fallback de provedor, enriquecimento opcional ou etapa de renderização podem ocultar o custo real.
• Uma correção de desempenho proposta precisa de uma comparação repetível antes e depois.

Não ative esta habilidade para um bug de correção, a menos que o desempenho também seja parte da falha observada.

Reproduza o Caminho Real

Registre uma carga de trabalho fixa antes de editar o código:

• fonte solicitada, hora, local, variáveis e saída;
• commit da aplicação e versão de tempo de execução;
• implementação ou backend ativo, incluindo motivo do fallback;
• estado de cache frio ou cache quente;
• máquina, sistema operacional, contagem de workers e limites de recursos relevantes;
• bytes transferidos e tamanho do artefato final;
• se orientações opcionais, sobreposições ou fontes secundárias foram ativadas.

Use a mesma carga de trabalho para a medição de linha de base e candidata. Uma execução mais rápida com menos entradas ou um cache quente não é evidência de que o caminho original melhorou.

Divida o Pipeline em Estágios

No mínimo, cronometre esses limites independentemente:

1. validação de solicitação e descoberta de fonte;
2. verificações de disponibilidade e seleção de fallback;
3. transferência de rede ou leitura de cache;
4. análise ou decodificação;
5. recuperação de dados suplementares;
6. construção de perfil, grade ou valores derivados;
7. visualização ou exportação;
8. limpeza e publicação final.

Adicione sub-estágios apenas onde a primeira passagem mostrar tempo significativo. Preserve o comportamento existente ao instrumentar; os diagnósticos não devem desabilitar silenciosamente trabalhos caros.

Exemplo de Cronometragem Leve

Use um relógio monotônico e emita registros estruturados que possam ser comparados entre execuções:

import json
import time
from contextlib import contextmanager


@contextmanager
def timed_stage(name, report):
    started = time.perf_counter()
    outcome = "ok"
    try:
        yield
    except BaseException:
        outcome = "error"
        raise
    finally:
        report.append({
            "stage": name,
            "outcome": outcome,
            "seconds": round(time.perf_counter() - started, 6),
        })


timings = []
with timed_stage("source_discovery", timings):
    source = discover_source()
with timed_stage("transfer", timings):
    local_path = fetch_source(source)
with timed_stage("processing", timings):
    result = build_result(local_path)

print(json.dumps(timings, sort_keys=True))

Instrumente os limites de produção ou as mesmas APIs públicas usadas pela produção. Evite um auxiliar de benchmark que contorne o caminho que os usuários relatam como lento.

Interprete as Evidências

• Longa descoberta com pouca transferência sugere listagens amplas, tentativas excessivas, timeouts de provedor ou sondagens de disponibilidade repetidas.
• Longa transferência com tempo de análise esperado sugere largura de banda, tamanho do objeto, limitação de taxa ou falha em reutilizar um cache válido.
• Longa análise requer prova de que o backend pretendido está ativo e que o volume de entrada é comparável.
• Longo processamento após a análise aponta para interpolação, recuperação secundária, construção de perfil ou computação repetida.
• Longa renderização pode vir de layout, rasterização, carregamento de fontes, redesenhos excessivos ou grandes dimensões de saída.
• Alta variância entre execuções idênticas sugere serviços externos, contenção, inícios a frio, coleta de lixo ou paralelismo descontrolado.

Meça o tempo de parede, tempo de CPU, bytes, contagem de itens, estado do cache e contagem de workers onde eles explicam o resultado. Uma única duração total não pode localizar um gargalo.

Valide uma Correção

1. Preserve o relatório de linha de base e a descrição do ambiente.
2. Altere a menor causa compartilhada suportada pelas medições.
3. Execute novamente a carga de trabalho idêntica várias vezes no mesmo estado de cache.
4. Compare o estágio afetado, a duração total, a identidade da saída e o uso de recursos.
5. Execute testes de correção para o caminho alterado.
6. Relate tanto a melhoria quanto a variabilidade da medição.

…