Que latência de gateway de execução desktop as equipes devem exigir?

Um gateway de execução desktop só merece seu lugar se o atraso da máquina ficar abaixo do ruído do trabalho interativo e se o atraso de aprovação for informado separadamente. Eu não aprovaria uma implantação com base em uma média, em uma única execução aquecida ou em um gráfico que misture uma pessoa levando a mão ao Touch ID com o tempo de execução do software. Esses números podem parecer organizados, mas não dizem à equipe de engenharia se o gateway vai interromper o ciclo editar-testar.

Para trabalho HTTP comum e SSH já conectado, uso como critério inicial de adoção no máximo 25 ms adicionais no p50 e 75 ms no p95 nos Macs dos desenvolvedores que serão usados. Para conexões SSH novas, use um orçamento separado e maior: no máximo 50 ms adicionais no p50 e 150 ms no p95. Considere esses valores requisitos iniciais, não constantes universais. A equipe deve torná-los mais rígidos ou flexíveis conforme sua própria linha de base direta, frequência de chamadas, rede e testes de percepção. O teste abaixo produz as evidências necessárias para tomar essa decisão sem esconder uma cauda lenta atrás de uma mediana aceitável.

Os percentis precisam descrever a mesma operação

Os valores de p50 e p95 só significam algo quando cada amostra representa o mesmo limite. p50 é a mediana: metade das chamadas observadas terminou nesse valor ou abaixo dele. p95 é o valor no qual ou abaixo do qual terminaram 95 por cento delas. Em uma execução com 200 amostras ordenadas, o p95 é o 190º valor pela definição de posto mais próximo. Assim, dez observações mais lentas continuam visíveis na cauda, em vez de serem diluídas pela média.

Defina o limite como o tempo desde o início de uma operação pelo chamador até ele receber o resultado completo. Esse é o atraso percebido por um agente de programação. Ele inclui o trabalho do processo local, o transporte até o destino, a execução remota, a transferência da resposta e qualquer trabalho do gateway nesse caminho. Exclui a preparação do benchmark e, na faixa sem supervisão, exclui a confirmação humana.

As equipes frequentemente comparam limites diferentes. Um gráfico de HTTP direto pode usar time_starttransfer do curl, enquanto o gráfico do gateway usa o tempo total de parede de uma chamada de processo. O primeiro para no byte inicial da resposta, o segundo para quando o resultado foi serializado e devolvido. O gateway perde antes do início do teste. Escolha a conclusão total para ambos os caminhos e mantenha os tempos das fases como colunas de diagnóstico.

A mesma regra vale para SSH. Uma nova conexão TCP, o handshake SSH, a autenticação, o comando remoto e a desconexão formam uma operação. Um comando enviado por uma conexão multiplexada existente é outra operação. Informe-os em linhas separadas. Misturá-los cria uma distribuição cujo p50 descreve principalmente a reutilização e cujo p95 descreve principalmente a criação da conexão. Nenhum limite corrige uma população confusa.

Informe pelo menos estas colunas para cada classe de operação:

• p50 e p95 do tempo de parede direto
• p50 e p95 do tempo de parede intermediado
• p50 e p95 adicionados, calculados com amostras pareadas
• número de amostras, falhas e timeouts
• host, condição de rede, versão do gateway e modo de aprovação

A latência adicional pareada importa mais que subtrair dois percentis de destaque. Para a amostra i, calcule delta_i = brokered_i - direct_i na mesma condição de teste e então obtenha o p50 e o p95 dos deltas. p95(brokered) - p95(direct) oferece contexto útil, mas não é a sobrecarga no p95 e pode até esconder a correlação entre picos de rede e trabalho do gateway.

Um contrato de benchmark evita resultados convenientes

Escreva o contrato do benchmark antes de executá-lo, pois quase toda otimização acidental muda a pergunta. Registre o modelo do Mac e a versão do macOS, se está ligado à energia, estado térmico, caminho de rede, região do host de destino, protocolo HTTP, negociação de cifra SSH, tamanhos de payload e resposta, timeout, concorrência e reutilização de conexão. Mantenha a carga em segundo plano representativa da máquina de um desenvolvedor. Um notebook impecável, com todos os editores e processos de build fechados, responde a uma pergunta de laboratório.

Use um destino local e um destino remoto realista. O destino local revela a sobrecarga da máquina porque a variação da rede é pequena. O destino remoto mostra se essa sobrecarga ainda importa em meio ao atraso real de transporte. Um gateway que acrescenta 40 ms a uma solicitação de loopback de 3 ms é percebido de modo muito diferente do mesmo acréscimo a uma chamada remota de 300 ms, mas ambos os resultados pertencem ao relatório.

Crie classes de operação em vez de uma única suíte combinada. Um mínimo útil é uma resposta HTTP pequena em conexão reutilizada, uma resposta HTTP pequena em conexão nova, uma conexão SSH nova que executa true e um comando SSH em uma conexão já disponível. Acrescente um payload representativo e uma resposta representativa do fluxo de programação da equipe. Não use uma API destrutiva ou um host SSH de produção para um teste de latência.

Execute um aquecimento que nunca entre no conjunto de amostras. Em seguida, colete pelo menos 200 chamadas medidas por classe, alternando a ordem direta e intermediada. Se todas as chamadas diretas forem executadas primeiro, uma mudança térmica posterior, mudança de rede, cache DNS ou cache do servidor vira sobrecarga do gateway. Ordem aleatória é aceitável, mas a alternância estrita é mais fácil de inspecionar.

Mantenha a concorrência em um no benchmark interativo. Um agente que espera o resultado de uma ferramenta é um usuário serial. Execute um segundo teste de carga se vários agentes compartilharem o gateway, mas identifique-o como trabalho de capacidade. Um teste com 20 chamadas simultâneas pode revelar limites de fila, mas não substitui o resultado de latência de uma única chamada.

As falhas permanecem no relatório. Registre um timeout como falha com seu valor de timeout decorrido e publique a taxa de falhas ao lado dos percentis. Remover silenciosamente os erros favorece um caminho que falha rápido ou descarta suas chamadas mais lentas. Se algum caminho falhar a ponto de tornar seu p95 instável, pare de discutir milissegundos e corrija primeiro a confiabilidade.

Meça HTTP sem alterar sua semântica

Use o mesmo método, URL, cabeçalhos, corpo, timeout e consumo da resposta para HTTP direto e intermediado. A fonte da credencial pode ser diferente porque o isolamento de credenciais é o objetivo do gateway, mas o servidor precisa receber solicitações com semântica equivalente. Confirme que ambas as variantes recebem o mesmo status, os cabeçalhos de resposta selecionados e o hash do corpo antes de coletar os dados de tempo.

O curl expõe relógios úteis de fase em suas variáveis documentadas de write-out. time_connect termina quando a conexão de rede é concluída, time_appconnect inclui o handshake TLS, time_starttransfer chega ao primeiro byte da resposta e time_total chega à conclusão. Esses valores ajudam a localizar uma regressão, mas o tempo de parede do chamador continua sendo o limite de comparação, pois um intermediário pode trabalhar antes do curl ou após a resposta upstream.

Esta sondagem direta imprime quatro campos em segundos sem adicionar um link ou analisar saída de progresso:

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}
' -H "$AUTH_HEADER" "$ENDPOINT"

Para a medição pareada, coloque a chamada direta completa em DIRECT_CMD e a chamada completa pelo gateway em BROKER_CMD. O executor a seguir alterna sua ordem, usa um relógio monotônico, preserva falhas e emite um objeto JSON por observação. Ele trata deliberadamente cada comando como um vetor de argumentos, de modo que operadores e expansões do shell não entrem no benchmark.

import json
import os
import shlex
import subprocess
import time

samples = int(os.environ.get("SAMPLES", "200"))
timeout = float(os.environ.get("TIMEOUT", "10"))
commands = {
    "direct": shlex.split(os.environ["DIRECT_CMD"]),
    "brokered": shlex.split(os.environ["BROKER_CMD"]),
}

for n in range(10):
    label = "direct" if n % 2 == 0 else "brokered"
    subprocess.run(commands[label], stdout=subprocess.DEVNULL,
                   stderr=subprocess.DEVNULL, timeout=timeout)

for n in range(samples):
    order = ("direct", "brokered") if n % 2 == 0 else ("brokered", "direct")
    for label in order:
        started = time.monotonic_ns()
        try:
            result = subprocess.run(commands[label], capture_output=True,
                                    timeout=timeout)
            ok = result.returncode == 0
            code = result.returncode
        except subprocess.TimeoutExpired:
            ok = False
            code = None
        elapsed_ms = (time.monotonic_ns() - started) / 1_000_000
        print(json.dumps({"pair": n, "path": label, "ms": elapsed_ms,
                          "ok": ok, "code": code}, separators=(",", ":")))

Capture a saída em um arquivo JSON Lines. Antes de calcular a latência, compare códigos de sucesso e hashes de resposta fora do loop cronometrado. Uma solicitação intermediada que retorna menos dados parecerá mais rápida. Uma solicitação direta que segue redirecionamentos enquanto a intermediada não segue medirá trabalhos diferentes.

A reutilização de conexão merece controle explícito. Se o protocolo do agente e o gateway mantêm uma conexão HTTP upstream, compare-a com um cliente direto que também a mantém. Iniciar um novo processo curl para cada amostra direta pode eliminar a reutilização de conexão e favorecer o caminho intermediado. Para um teste baseado em processos, force conexões novas nos dois lados ou crie dois pequenos clientes persistentes. Publique qual opção você escolheu.

SSH exige medições frias e reutilizadas

A configuração de SSH costuma dominar um comando remoto curto, portanto um único percentil de SSH diz pouco. O manual do cliente OpenSSH documenta o compartilhamento de conexões com ControlMaster e ControlPersist. Com o compartilhamento ativado, sessões posteriores podem reutilizar uma conexão de rede existente em vez de repetir a configuração de transporte e a autenticação. Essa é uma otimização válida para produção, desde que ambos os caminhos tenham chance equivalente de usá-la.

Para uma classe de conexão nova, desative o compartilhamento, execute um comando inofensivo como true e desconecte. Em um host de teste dedicado, um comando direto pode ser assim:

ssh -F /dev/null -o BatchMode=yes -o ControlMaster=no -o ConnectTimeout=10 "$TEST_HOST" true

Use a ação SSH normal do gateway para a chamada intermediada pareada, com o mesmo host, usuário e comando remoto. Não force o gateway a uma preparação artificial que o agente jamais usaria. Em vez disso, faça o caminho direto acompanhar o comportamento de conexão documentado do gateway ou declare a diferença de arquitetura no resultado.

Para a classe reutilizada, estabeleça a conexão antes do aquecimento e execute apenas o comando remoto true durante a amostragem. Verifique a reutilização em vez de supô-la. Os diagnósticos detalhados do OpenSSH podem mostrar se o cliente contata um socket de controle. O gateway deve expor tempos de diagnóstico ou logs suficientes para comprovar se reutilizou o transporte. Se a reutilização não puder ser comprovada, identifique a classe como "estado de conexão desconhecido" e não a compare com um caminho comprovadamente reutilizado.

Depois, repita com uma tarefa real não destrutiva, como ler um arquivo pequeno e fixo ou consultar o status de um serviço de teste. true isola a infraestrutura de conexão e execução, mas não cobre transferência de saída, decodificação ou limites de resultado. Mantenha o conteúdo do arquivo fixo e calcule o hash dos bytes retornados.

A autenticação SSH também muda a comparação. Um agente não deve receber uma chave privada apenas para tornar conveniente a linha de base direta. Execute o caminho direto em um ambiente isolado, com acesso de rede equivalente, e trate a exposição de credenciais como um recurso do benchmark, não como um projeto recomendado. A latência informa o custo da mediação. Ela não decide se é aceitável entregar uma chave a um processo autônomo.

Instrumente o gateway em torno do próprio trabalho

Um cronômetro externo comprova o resultado visível para o usuário, enquanto timestamps internos explicam esse resultado. Adicione timestamps monotônicos no recebimento, ao concluir a validação da solicitação, ao concluir a decisão de autorização, ao concluir a operação de credencial, no envio upstream, no primeiro byte upstream, na conclusão upstream, na confirmação da auditoria e na entrega do resultado. Registre durações ou um identificador de rastreamento compartilhado, nunca segredos ou corpos de solicitação.

Esses timestamps dividem o atraso adicional da máquina em partes sobre as quais a equipe pode agir:

• análise e serialização do protocolo local
• consulta de autorização e eventual espera em fila
• operação de cofre ou credencial
• configuração do cliente upstream e obtenção de conexão
• persistência da auditoria e retorno do resultado

Não compare timestamps de relógio de parede de processos diferentes, a menos que o desenho de medição trate as diferenças de relógio. Em um Mac, um relógio monotônico em cada processo é estável para durações, mas as origens podem não se alinhar entre runtimes. O desenho mais seguro faz cada componente informar sua própria duração e une os registros por um identificador de teste opaco.

O trabalho de auditoria pertence ao limite medido se o gateway promete que uma ação é registrada antes de informar sucesso. Mover a gravação para depois da resposta pode melhorar o benchmark à custa da garantia. O envio em lote pode ser legítimo, mas o ponto de durabilidade publicado precisa corresponder à produção. O teste deve medir o produto que as pessoas usarão, com seu journal normal e os controles de segurança ativados.

Faça profiling somente depois que os dados de fase apontarem um suspeito. Se o p50 sobe com o tamanho da resposta, inspecione cópias e serialização. Se o p95 sobe enquanto o p50 permanece estável, inspecione locks, esperas em fila, gravações de auditoria, ausências no pool de conexões e agendamento do sistema operacional. Um perfil de CPU de uma chamada mediana silenciosa raramente explica uma parada na cauda.

Proteja o próprio benchmark do custo de observação. Logs detalhados em um terminal podem adicionar E/S bloqueante. Grave registros compactos em um arquivo ou buffer na memória, meça uma vez com eventos de diagnóstico ativados e confirme que a diferença é desprezível. Sempre que possível, mantenha o modo de diagnóstico consistente entre execuções diretas e intermediadas.

A confirmação humana é outro nível de serviço

O tempo de confirmação começa quando o cartão de aprovação fica visível e termina quando a decisão chega à chamada bloqueada. Ele não é latência de máquina do gateway. Combiná-lo com chamadas automáticas produz um p95 influenciado pela posição da mão, atenção, estado da tela e interrupções. Essa pode ser uma medida importante do fluxo de trabalho, mas ela responde se a aprovação se encaixa no trabalho, não se o caminho de execução é eficiente.

Informe três distribuições para ações protegidas. Primeiro, registre o tempo de máquina do gateway antes do prompt. Segundo, registre do prompt visível até a decisão. Terceiro, registre o tempo de máquina após a decisão até a entrega do resultado. O valor de ponta a ponta pode aparecer ao lado delas, desde que ninguém o use para diagnosticar sobrecarga de transporte.

Não automatize cliques e chame isso de latência humana. A automação pode medir a apresentação e a infraestrutura de decisão, que pertencem aos grupos de máquina. Um estudo com pessoas precisa de participantes consentindo, uma tarefa definida e timestamps de eventos que não capturem entrada sensível. Informe o número de participantes e se eles esperavam o prompt. Uma confirmação esperada pelo Touch ID em um teste com roteiro será mais rápida que uma aprovação inesperada durante programação real.

Os modos de aprovação também exigem linhas separadas. Uma ação permitida para uma sessão já autorizada, uma primeira chamada que pede autorização do processo e uma confirmação por chamada têm caminhos diferentes por definição. Misture-os e o resultado dependerá da frequência acidental de cada um na amostra.

Um orçamento de fluxo útil descreve a interrupção sem fingir que toda aprovação precisa caber em 100 ms. Por exemplo, exija que o cartão apareça em até 150 ms após a chamada chegar ao gateway no p95 e depois meça o tempo de decisão humana sem meta de aprovação ou reprovação até a equipe observar o uso real. Defina uma meta posterior com base em abandono, aprovações equivocadas e perturbação da tarefa. Uma aprovação rápida é ruim se o cartão omite a identidade ou os detalhes da ação necessários para uma boa decisão.

Calcule os deltas antes de desenhar o gráfico

A calculadora de resultados deve parear as observações, rejeitar pares incompletos da distribuição de latência e informar esses pares incompletos como falhas. Isso impede que uma chamada direta bem-sucedida seja comparada à próxima chamada intermediada depois que sua parceira real atingiu timeout. Mantenha o número do par do executor como campo de união.

Use uma definição de percentil em todos os lugares. O método do posto mais próximo ordena os valores e seleciona o posto ceil(p * n), com os postos começando em um. Bibliotecas oferecem percentis interpolados que podem retornar um valor que ninguém observou. A interpolação é legítima em algumas análises, mas mudar de método entre um notebook e um dashboard cria discussões desnecessárias perto de um limite. Declare o método no relatório.

Esta pequena calculadora consome o JSON Lines emitido pelo executor anterior. Ela imprime contagens, p50 e p95 de posto mais próximo para tempo direto, tempo intermediado e tempo adicional pareado:

import json
import math
import sys

rows = [json.loads(line) for line in sys.stdin if line.strip()]
by_pair = {}
failures = {"direct": 0, "brokered": 0}

for row in rows:
    if not row["ok"]:
        failures[row["path"]] += 1
        continue
    by_pair.setdefault(row["pair"], {})[row["path"]] = row["ms"]

direct = []
brokered = []
deltas = []
for pair in sorted(by_pair):
    values = by_pair[pair]
    if "direct" not in values or "brokered" not in values:
        continue
    direct.append(values["direct"])
    brokered.append(values["brokered"])
    deltas.append(values["brokered"] - values["direct"])

def percentile(values, fraction):
    ordered = sorted(values)
    rank = max(1, math.ceil(fraction * len(ordered)))
    return ordered[rank - 1]

result = {"complete_pairs": len(deltas), "failures": failures}
for name, values in (("direct", direct), ("brokered", brokered),
                     ("added", deltas)):
    result[name] = {
        "p50_ms": percentile(values, 0.50),
        "p95_ms": percentile(values, 0.95),
        "max_ms": max(values),
    }
print(json.dumps(result, separators=(",", ":")))

O formato de saída é deliberadamente simples: complete_pairs, contagens de falhas para cada caminho e um bloco para cada distribuição com p50_ms, p95_ms e max_ms. Acrescente intervalos de confiança se a equipe já os utiliza, mas não deixe que um intervalo substitua a inspeção bruta da cauda. Um percentil pode mudar entre execuções porque o sistema mudou ou porque a amostragem variou. As linhas brutas mostram qual explicação se encaixa.

Deltas negativos são válidos. Eles podem surgir quando o intermediário reutiliza uma conexão que o comando direto abre novamente, ou quando o ruído normal da rede favorece o membro intermediado de um par. Não os limite a zero. Em vez disso, corrija uma configuração injusta de conexão ou permita que a distribuição pareada mantenha a variância. Limitar os valores introduz viés de alta em todos os percentis e dificulta a auditoria do cálculo.

Preserve a precisão total nos dados e arredonde apenas os valores de apresentação, de preferência para um décimo de milissegundo. A avaliação dos limites deve usar o número não arredondado. Um valor informado como 75,0 ms pode representar um resultado pouco acima do limite de 75 ms se a formatação ocorrer antes da comparação.

A latência de cauda mostra onde a confiança se desgasta

A programação interativa é mais prejudicada por atrasos irregulares do que por uma pequena sobrecarga estável. Um desenvolvedor consegue se adaptar a 15 ms extras em toda chamada de ferramenta. Uma pausa aleatória de 800 ms faz o agente parecer quebrado, especialmente quando várias chamadas ocorrem em sequência. Por isso, o p95 é um requisito de adoção, não um gráfico decorativo.

Inspecione as observações brutas da cauda. Identifique se cada uma coincidiu com ausência de conexão HTTP, handshake SSH, desbloqueio do cofre, gravação de auditoria, ativação do app, pressão de CPU ou pico de rede. Não elimine um valor atípico só porque consegue explicá-lo. Se essa condição existir na produção, ela pertence à distribuição. Remova apenas um defeito comprovado do teste, preserve os dados originais e publique a regra de exclusão.

p99 pode ajudar durante a engenharia, mas é instável com amostras pequenas. Com 200 chamadas, o p99 depende de aproximadamente as duas observações mais lentas. Exijo p50 e p95 para adoção e depois inspeciono o máximo e as linhas brutas da cauda em busca de padrões de falha. Uma execução noturna mais longa pode embasar o trabalho com p99 depois que o limite interativo for atingido.

Estados aquecidos e frios precisam permanecer visíveis. Meça a abertura do app ou o desbloqueio do cofre como uma operação própria se os usuários os encontram, mas não os misture às chamadas estáveis. Da mesma forma, informe separadamente a recuperação após repouso e ativação do Mac. Um app desktop sempre em execução pode parecer excelente após o aquecimento e ainda assim lidar mal com a primeira ação depois do almoço.

O custo da sequência também entra na decisão. Se uma tarefa de programação faz doze chamadas seriais, os atrasos adicionais se acumulam. Reproduzir uma sequência de ações capturada e sem dados sensíveis pode revelar custos que solicitações isoladas não mostram, como churn do pool ou um journal que fica mais lento conforme a sessão cresce. Mantenha as distribuições de operações individuais e acrescente o delta de conclusão da tarefa como medida secundária.

Defina o limite pelo custo de interação

O gateway passa quando o atraso adicional de máquina é pequeno em termos absolutos e também em relação ao caminho direto. Começo com quatro limites para um desktop atual sob carga representativa:

• HTTP com reutilização: 25 ms no p50 e 75 ms no p95
• HTTP com conexão nova: 30 ms no p50 e 100 ms no p95
• SSH com conexão reutilizada: 25 ms no p50 e 75 ms no p95
• SSH com conexão nova: 50 ms no p50 e 150 ms no p95

Aplique a verificação relativa quando o p95 direto for de pelo menos 100 ms. Em uma chamada de loopback de 3 ms, uma regra de 20 por cento permite menos de um milissegundo e mede principalmente ruído. Em uma chamada remota lenta, um limite absoluto isolado pode permitir uma implementação que acrescenta uma grande fração do tempo direto. As duas verificações cobrem contextos diferentes.

Exija uma taxa de falhas no máximo igual à direta mais uma pequena tolerância declarada e investigue automaticamente qualquer timeout causado pelo gateway. Eu não trocaria confiabilidade por um ganho de 10 ms na mediana. Exija também equivalência correta dos resultados e a durabilidade de auditoria pretendida. Um caminho rápido que altera a resposta ou a registra depois falhou em um teste diferente e mais grave.

Execute o limite na classe de Mac suportada mais lenta que a equipe realmente usa, não apenas na máquina mais nova da bancada. Repita ligado à energia e sob carga de um editor representativo mais build. Para destinos remotos, exija três execuções em dias ou períodos de rede diferentes. Isso não é cerimônia estatística, pois impede que uma janela de rede favorável se torne uma promessa de produto.

As equipes podem ajustar os números iniciais com um teste de percepção às cegas. Injete atrasos fixos em um gateway simulado, reproduza uma tarefa típica do agente e peça aos desenvolvedores que avaliem a interrupção sem informar o atraso. Escolha o menor atraso que gera reclamação consistente e coloque o limite p95 abaixo dele, com margem. Preserve a margem de 150 ms para SSH novo somente se o handshake direto já dominar e a tarefa completa ainda parecer imediata.

Rejeite a implantação se uma operação comum não atingir o limite p95, mesmo que o gráfico combinado passe. Uma média ponderada permite que chamadas HTTP rápidas e frequentes escondam ações SSH lentas. Aprove por classe de operação e depois revise a sequência de tarefas capturada para confirmar que vários custos aceitáveis não se somam em uma pausa inaceitável.

Torne a adoção reversível e baseada em evidências

A adoção deve começar com um grupo canário e uma condição de reversão registrada. Congele o script de benchmark, os recursos de teste, a configuração do gateway e a calculadora de resultados no controle de versão. Salve as observações brutas, não capturas de tela. Quem revisar a decisão deve conseguir recalcular os percentis e ver todas as falhas.

Para o Sallyport, execute o mesmo ambiente de teste por seus canais HTTP e SSH, com o cofre, a autorização de sessão, a configuração por chamada e o comportamento de auditoria definidos exatamente como exige a implantação pretendida. Seu log de auditoria criptografado e encadeado por hash pode ser verificado offline com sp audit verify. Execute isso após o benchmark para que o relatório de latência e a verificação de integridade descrevam as mesmas chamadas.

Avance apenas quando cada classe de operação passar em Macs representativos, os hashes dos resultados coincidirem, a verificação da auditoria for bem-sucedida e os desenvolvedores aceitarem a reprodução da tarefa completa. Mantenha um caminho direto de escape durante o canário, mas registre cada uso e seu motivo. Se as pessoas ignorarem o gateway porque o p95 parece irregular, o benchmark não capturou o fluxo de trabalho. Corrija a medição antes de ampliar a implantação.