Simple Message Queue (SMQ, formerly MNS) oferece dois métodos para consumir mensagens de uma fila: short polling e long polling. Escolha o método com base nos requisitos de latência e custo.
O short polling retorna resposta imediata, haja ou não mensagem disponível. Essa abordagem minimiza a latência por requisição, mas pode gerar alto volume de respostas vazias.
O long polling mantém a conexão aberta até a chegada de uma mensagem ou o fim do período de espera. Esse método reduz respostas vazias e custos, sendo recomendado para a maioria das cargas de trabalho.
Funcionamento do short polling
No short polling, o cluster SMQ responde imediatamente a cada requisição de recebimento. Se não houver mensagem disponível, a resposta indicará resultado vazio.
Para ativar o short polling, cumpra uma das condições a seguir:
Defina o período de long polling como
0ao criar a fila.Defina o parâmetro
waitSecondscomo0ao chamar a operação da API para receber mensagens.
Qualquer uma dessas condições aciona o short polling. Como o servidor responde instantaneamente, sem verificar a disponibilidade de mensagens, requisições frequentes a filas vazias geram chamadas de API desnecessárias e aumentam os custos.
Funcionamento do long polling
No long polling, o servidor mantém a conexão aberta e responde apenas quando uma mensagem chega ou o período de espera expira. Isso elimina respostas vazias durante a janela de espera e reduz o total de chamadas de API.
Para ativar o long polling, cumpra uma das condições a seguir:
Defina o período de long polling com valor maior que
0(até 30 segundos) ao criar a fila.Defina o parâmetro
waitSecondscom valor maior que0ao chamar a operação da API para receber mensagens.
Se o período de long polling da fila e o parâmetro waitSeconds da requisição estiverem definidos simultaneamente, o valor de waitSeconds terá precedência.
Benefícios do long polling
Entrega imediata: As mensagens retornam assim que chegam, sem aguardar o próximo ciclo de polling.
Menos respostas vazias: O servidor retém a requisição até haver mensagem disponível, evitando que filas ociosas gerem respostas vazias constantemente.
Custos reduzidos: Menor número de requisições de API resulta em custos de mensageria mais baixos.
Referência de configuração
|
Parâmetro |
Nível |
Valor para short polling |
Valor para long polling |
Máximo |
|
Período de long polling |
Fila (definido na criação) |
|
Maior que |
30 segundos |
|
|
Requisição de API (receber mensagem) |
|
Maior que |
30 segundos |
Regra de precedência: O valor de waitSeconds em uma requisição de API substitui o período de long polling configurado para a fila.
Melhores práticas
Prefira o long polling para a maioria das cargas de trabalho. O short polling é adequado apenas quando a aplicação exige tempos de resposta abaixo de um segundo na própria chamada de recebimento, independentemente da disponibilidade de mensagens.
Aumente o período de long polling se observar respostas vazias frequentes. Caso o consumidor envie alto volume de requisições de recebimento, mas a maioria retorne vazia, aumente o período de long polling para reduzir chamadas de API desnecessárias e diminuir custos.