Throughput

Estes são números reais de uma execução real, não projeções. Leia as ressalvas antes de citar qualquer um deles — a bancada usou um SMSC de teste, e a descoberta mais útil é sobre isso.

​

O baseline

O burst corrigido é o que se deve comparar contra trabalhos futuros: 752 msg/s entregues, 98,9% de sucesso, 26,3 s para 20 000 mensagens.

​

O router nunca foi o gargalo

fireflo_router_queue marcou 0 durante todo o burst de 20 000 mensagens e teve pico de 18 em toda outra execução. Mensagens estavam sendo roteadas tão rápido quanto chegavam; depois se acumulavam na fila do worker do fornecedor, que atingiu 7 987. Tudo que limitava o throughput estava a jusante do código de roteamento.

​

A linha única que cortou perda em 92%

O primeiro burst perdeu 2 528 mensagens, cada uma message.dropped reason=maxAttempts attempts=20 limit=20, com 151 985 tentativas de submit para 24 000 mensagens aceitas — cerca de seis cada. A conexão do fornecedor nunca caiu. Isto não era conectividade. O SMSC de teste parou de responder rápido o bastante sob burst, submits expiraram, o worker fez retry, e mensagens que usaram todas as 20 tentativas de roteamento foram abandonadas. Re-executando com transceivers = 1 — mesmas mensagens, mesma janela, mesmas threads de router: A fila ainda atingiu 8 042 e o router ainda nunca ficou atrás, então a forma da execução foi idêntica. O que mudou é que uma sessão única não provoca o que quer que o SMSC de teste faça quando over-sessioned.

​

A alavanca que parecia óbvia e não fez nada

Uma versão anterior do baseline dizia que o fix para o 1,1% residual era aumentar outSms.routing.maxAttempts e outSms.routing.retryBackoffMillis, argumentando que uma mensagem sobrevive apenas cerca de dois segundos de um fornecedor não aceitando. Isso foi medido e está errado. Sem melhoria, e marginalmente mais lento. Mais retries contra um fornecedor que não está aceitando é mais carga sobre a coisa já recusando. O que consertou foi vendor1.tps = 300 — pacear o gateway ao que o fornecedor realmente conseguia receber. Zero perdidas, zero ESME_RMSGQFUL, e exatamente 1,00 submits por mensagem.

​

O que medir no seu próprio deployment

​

Ressalvas

• Um SMSC de teste não é uma operadora. As duas execuções de burst foram limitadas pelo simulador, não pelo FireFlo.
• A variação entre execuções foi maior que o efeito da configuração de janela. Aumentar windowSize 100 → 500 e transceivers 1 → 4 produziu 337 e 910 msg/s em duas execuções de configuração idêntica, contra 500 e 840 do baseline. Esta bancada não pode resolver esse efeito — o que é uma afirmação sobre a medição, não uma evidência de que a janela não importa.
• message.trace.mode = all produziu 226 MB de log para uma execução de 20 000 mensagens. Útil para uma investigação, ruinoso como padrão.

​

Relacionado