Maximizar o rendimento com o RabbitMQ
no nosso projecto, queremos usar o RabbitMQ no padrão de "filas de tarefas" para passar dados.
do lado do produtor, construímos alguns servidores TCP (no nó.js) a recv dados de alta competição e enviá-lo para MQ sem fazer nada.
Do lado do consumidor, usamos o cliente JAVA para obter os dados da tarefa de MQ, trata disso e depois ack. Então a questão é:: Para obter o máximo de mensagens de transmissão/desempenho (por exemplo, 400.000 msg/segundo) , quantas filas são melhores? Será que mais fila significa melhor rendimento/desempenho? E há mais alguma coisa que deva reparar? Algum guia de boas práticas conhecido para usar RabbitMQ nesse cenário?todos os comentários são muito apreciados!!
3 answers
Para melhor desempenho em RabbitMQ, siga o conselho de seus criadores. From the RabbitMQ blog:
As filas do RabbitMQ são mais rápidas quando estão vazias. Quando uma fila é vazio, e tem os consumidores prontos para receber mensagens, logo que uma mensagem é recebida pela fila, vai directamente para o consumidor. No caso de uma mensagem persistente em uma fila durável, sim, ele também vai para o disco, mas isso é feito de uma maneira assíncrona e é fortemente tamponado. O ponto principal é que muito pouca contabilidade é preciso fazer, muito poucas estruturas de dados são modificadas, e muito pouca memória adicional precisa de ser alocada.
Se você realmente quer investigar profundamente o desempenho das filas RabbitMQ, este outro item do blog deles vai para os dados muito mais longe.
De acordo com uma resposta que recebi uma vez do grupo rabbitmq-discuss mailing group há outras coisas que você pode tentar aumentar o rendimento e reduzir a latência:
Usa uma contagem de pré-Vetch maior. Os pequenos valores prejudicam o desempenho.
Uma troca de tópicos é mais lenta do que uma troca direta ou fanout.
Certifiquem-se de que as filas ficam curtas. Filas mais longas impõem mais processamento sobrecarga.
Se você se importa com a latência e taxas de mensagens em seguida, usar mensagens menores. Utilizar um formato eficiente (por exemplo, evitar XML) ou comprimir a carga útil.
Experimente com o HiPE, o que ajuda no desempenho.
Evitar transações e persistência. Também evitar a publicação no imediato ou modo obrigatório. Evite HA. O agrupamento também pode ter impacto no desempenho.
Obterá melhores resultados num sistema multi-core se tiver múltiplas filas e consumidores.
Utilização em pelo menos v2.8.1, que introduz o controlo do fluxo. Certifique-se de que os alarmes de memória e de espaço em disco nunca activam.
A virtualização pode impor uma pequena sanção de desempenho.
Afine o seu SO e a sua pilha de rede. Certifique-se de fornecer mais do que suficiente RAM. Fornecer núcleos rápidos e RAM.
Você vai aumentar o rendimento com uma contagem de pré-Vetch maior e ao mesmo tempo ACK múltiplas mensagens (em vez de enviar ACK para cada mensagem) do seu consumidor.
Mas, claro, ACK com bandeira múltipla ([[4]} http://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.ack ) requer uma lógica extra na sua aplicação ao consumidor (http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2013-August/029600.html . terá de manter uma lista de marcas de entrega da as mensagens enviadas pelo corretor, o seu estado (quer a sua aplicação as tenha tratado ou não) e ACK cada n-th delivery-tag (NDTAG), quando todas as mensagens com tag de entrega menos ou igual a NDTAG tiverem sido tratadas.