Resumo

  • RFC 9971 define MLRsearch, uma metodologia de benchmark de laboratório que procura uma ou mais metas explícitas de razão de perda e relata limites para cada meta sob sistema e tráfego declarados.
  • O throughput condicional descreve o ensaio que o produziu — escopo do sistema, perfil, carga, duração e meta — e não uma capacidade contratada, um resultado de aplicação ou uma obrigação de serviço.
  • Antes de usar o número para produção, compra ou compromisso, a organização precisa acrescentar evidência do ambiente real e uma decisão local que tenha dono e reversão.

O valor só significa algo dentro do experimento

RFC 9971 descreve Multiple Loss Ratio Search. A finalidade é melhorar repetibilidade e comparabilidade de benchmarks de plano de dados e, em muitos casos, reduzir o tempo de busca. O foco inclui funções de rede em software executadas sobre hardware comum, onde a variação do ambiente pode ser tão relevante quanto o programa observado.

Não se trata de descobrir um número eterno de “performance do produto”. O método organiza Trials com cargas e durações escolhidas para um ou mais Search Goals. Para alguém comparar o resultado, precisa conhecer o System Under Test, o perfil e a orientação do tráfego, os tamanhos de quadro, a carga oferecida, a razão de perda permitida, as durações e a largura escolhida para os limites. Quando esses elementos são retirados de um slide, o que sobra não é capacidade mensurada: é uma frase sem procedimento verificável.

O status também pede cuidado. RFC 9971 é Informational. A linguagem de BCP 14 torna precisa uma alegação de conformidade com MLRsearch, mas não obriga adoção nem atesta produto algum. O texto é independente de RFC 2544, não o altera nem o substitui. Um benchmark de objetivo único pode ser configurado para satisfazer condições de RFC 2544; isso depende do procedimento registrado, e não da simples referência ao novo RFC.

O SUT inclui a vizinhança da função

O RFC separa DUT de SUT. O primeiro é o dispositivo ou função cujo encaminhamento interessa. O segundo é o conjunto que recebe o estímulo e do qual se mede a resposta. Em uma função de software, esse conjunto pode abranger host, firmware, sistema operacional, hipervisor, drivers, NIC, I/O e outros trabalhos que disputam recursos. O mesmo binário pode produzir outra série de Trials quando muda o sistema ao redor.

RFC 9971 usa noise para abarcar interferência do SUT e oscilações internas difíceis de distinguir. Escalonamento de CPU, pressão de memória, atividade vizinha ou variação do próprio programa podem aparecer como perda. Um conjunto finito de testes não identifica, para cada quadro, a causa final. A contribuição do método é manter a incerteza dentro de uma estrutura de metas, limites e relatório, não fingir que ela desapareceu.

Portanto, o número fala de um SUT declarado naquele estado. Não demonstra uma propriedade atemporal da função, e não demonstra a capacidade de um serviço de produção com rotas, políticas, reenvios, dependências, falhas e mistura de clientes que não fizeram parte do ensaio.

Metas de perda tornam a escolha auditável

RFC 1242 define throughput como a maior taxa sem descarte de qualquer quadro oferecido. Essa definição é importante, mas perto do limite de sistemas de software podem ocorrer resultados inconsistentes: um Trial de carga maior pode registrar razão de perda menor que outro de carga inferior. Um único valor omite quem escolheu duração, precisão e tratamento para a inconsistência.

MLRsearch explicita esses papéis. O Manager configura as entidades e produz o Test Report; o Controller seleciona cargas e durações; o Measurer executa os Trials. São funções conceituais, não uma exigência de três ferramentas. Cada Search Goal tem parâmetros próprios. Em um resultado regular, a relevant lower bound e a relevant upper bound se aproximam segundo a goal width anunciada.

O método permite múltiplas metas de perda, mas não declara aceitável toda perda pequena não nula. O RFC observa que não existe consenso para uma meta universal e que a relação entre perda de teste e desempenho de camadas superiores não é simples. A mesma taxa não autoriza conclusão sobre TCP, chamada em tempo real, replicação ou transação. A tolerância é uma escolha local de quem sofrerá o efeito, e deve ser justificada no registro.

Repetibilidade não é mandato sobre produção

Repetir um benchmark bem definido ajuda a encontrar regressões em um laboratório. Também pode repetir, com excelente precisão, um perfil que não corresponde ao tráfego real. RFC 9971 deixa os algoritmos internos de seleção de carga do Controller como decisão de implementação e não escolhe uma configuração universal. Não é uma lacuna a ser preenchida por marketing; é a fronteira onde uma organização precisa declarar sua hipótese e seu apetite por risco.

Running-Code Primacy, de Heng Lu, dá o critério prático: a evidência relevante é o código executado, a configuração ativa, o tráfego efetivamente oferecido e o registro bruto. A marca “benchmark” não substitui essa cadeia. A ideia de decisão futura localizada acrescenta que uma linguagem comum permite comparação, mas não desloca para o autor do método a decisão sobre capacidade vendida, limiar de perda ou mudança operacional de outra parte.

Separe quatro registros antes de prometer algo

O primeiro registro é o benchmark: build, hardware, virtualização, perfil, metas, duração, ferramentas e resultados brutos. O segundo é a interpretação limitada, por exemplo que uma configuração não regrediu contra uma linha de base de laboratório. O terceiro é a evidência de produção: filas, CPU, I/O, retries, transações, orçamento de erro e canários no escopo real. O quarto é a decisão: quem aprova release, compra, reserva de capacidade ou rollback, com qual limiar, exceção e prazo.

O resultado pode informar uma compra, mas não substitui carga de aceitação e contrato. Pode informar planejamento, mas não substitui distribuição de pico, margem de falha e competição entre cargas. Pode entrar em um gate de release, mas não substitui compatibilidade, segurança, rollout gradual e retorno. Um SLA é promessa sobre serviço definido em período definido; não nasce de frames que passaram em um laboratório.

Do mesmo modo, uma cota inferior conservadora não reserva o futuro. Um resultado fraco não prova, por si, violação de fornecedor ou causa de incidente. Ambos devem iniciar uma hipótese testável, não encerrar uma decisão.

Fontes