Este documento descreve os resultados obtidos durante o estudo para avaliar a performance do RabbitMQ em um ambiente cloud. O objetivo do estudo era determinar os limites do RabbitMQ em um ambiente clusterizado e em nuvem, para definir, entre outras coisas, a forma de instalação e uso do RabbitMQ em tal cenário.
Os testes foram realizados tendo como premissa tentar simular um cenário o mais próximo possível de uma situação real.
O ambiente de execução dos testes foi disponibilizado com as seguintes características:
Para gerar carga a ser manipulada pelo RabbitMQ e assim poder avaliar seu desempenho, foi utilizada a ferramenta de teste de carga perf-test, disponibilizada pela Pivotal, desenvolvedora do RabbitMQ.
A ferramenta pode ser obtida no GitHub, como código fonte ou em formato binário. É desenvolvida em Java e permite avaliar um amplo número de situações através de parâmetros fornecidos por linha de comando ou como variáveis de ambiente, o que é interessante para uso em contêineres como o Docker.
Inclusive, está foi a abordagem adotada. Gerou-se uma imagem Docker contendo o programa de teste em formato binário. A imagem foi disponibilizada no repositório docker.totvs.io, com a tag rabbitmq/carga:latest.
Abaixo estão listados os parâmetros da ferramenta perf-test utilizados para realização dos testes de carga. Os parâmetros foram configurados como variáveis de ambiente nos arquivos de deployment das imagens do programa de teste.
Os valores de alguns parâmetros permaneceram fixos ao longo dos testes e estão descritos a seguir. Os valores que se modificaram conforme necessidade serão descritos nos cenários de teste correspondentes.
Conforme os valores acima, cada instância da imagem do programa de teste iniciará 10 threads para produção/consumo de mensagens (conforme o perfil), com as filas sendo nomeadas como perf-test-01, perf-test-02, e assim por diante. As mensagens produzidas, quando não for especificada variação de tamanho ao longo do tempo (VARIABLE_SIZE), serão de 3000 bytes.
O diagrama a seguir mostra como os elementos de software foram organizados no cluster Kubernetes para a realização dos testes:
Na representação acima, cada produtor (producer) e cada consumidor (consumer) representa um deployment, com parametrizações específicas para filas a criar. Por isso, cada um possui identificador específico, variando de 1 a 5. Entretanto, todas as instâncias foram geradas a partir da mesma imagem Docker relativa ao programa de testes.
Abaixo um exemplo de deployment do Kubernetes demonstrando as configurações relativas ao producer-1 para o último cenário de teste executado.
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: producer-1 namespace: producers labels: app: producer-1 spec: replicas: 0 selector: matchLabels: app: producer-1 template: metadata: labels: app: producer-1 spec: containers: - name: producers image: docker.totvs.io/rabbitmq/carga:latest imagePullPolicy: Always env: - name: PRODUCERS value: "10" - name: CONSUMERS value: "0" - name: QUEUE_PATTERN value: "perf-test-%02d" - name: QUEUE_PATTERN_FROM value: "1" - name: QUEUE_PATTERN_TO value: "10" - name: URI value: "amqp://admin:[email protected]:8081" # Varia o tamanhos das mensagens em um intervalo de tempo. Formato: <tamanho em bytes>:<segundos> - name: VARIABLE_SIZE value: "3000:60,1000:120,4000:60,500:300" # Varia a quantidade de mensagens em um intervalo de tempo. Formato: <qtde/segundo>:<segundos> - name: VARIABLE_RATE value: "30:60,100:120,300:60,50:300" # Máximo de mensagens em uma fila. 10000 é um limite que visa performance de entrega - name: QUEUE_ARGS value: "x-max-length=20000"
Conforme se pode verificar acima, cada instância de producer-1 iniciará 10 produtores (PRODUCERS), cada um associado a uma fila com nomes variando de "perf-test-01" a "perf-test-10" (QUEUE_PATTERN, QUEUE_PATTERN_FROM, QUEUE_PATTERN_TO).
O tamanho das mensagens variará da seguinte forma (VARIABLE_SIZE):
A taxa de produção de mensagens variará conforme segue (VARIABLE_RATE):
As filas serão criadas para receber o máximo de 20000 mensagens (QUEUE_ARGS).
A seguir, o arquivo de deployment do consumer-5, para o último cenário de teste.
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: consumer-5 namespace: consumers labels: app: consumer-5 spec: replicas: 0 selector: matchLabels: app: consumer-5 template: metadata: labels: app: consumer-5 spec: containers: - name: consumers image: docker.totvs.io/rabbitmq/carga:latest imagePullPolicy: Always env: - name: PRODUCERS value: "0" - name: CONSUMERS value: "10" - name: QUEUE_PATTERN value: "perf-test-%02d" - name: QUEUE_PATTERN_FROM value: "41" - name: QUEUE_PATTERN_TO value: "50" - name: URI value: "amqp://admin:[email protected]:8081/app2" # Máximo de mensagens em uma fila. 10000 é um limite que visa performance de entrega - name: QUEUE_ARGS value: "x-max-length=20000" # Consumer prefetch count: quantidade de mensagens que o consumidor obterá da fila a cada vez. - name: QOS value: "500"
No arquivo acima, cada instância do consumer-5 iniciará 10 threads (CONSUMERS) para consumir das filas cujos nomes variarão de "perf-test-41" a "perf-test-50" (QUEUE_PATTERN, QUEUE_PATTERN_FROM, QUEUE_PATTERN_TO).
As filas serão criadas para conter o máximo de 20000 mensagens (QUEUE_ARGS) e os consumidores recuperaram 500 mensagens a cada vez.
Os cenários a seguir apresentarão os parâmetros usados, procedimentos efetuados e as observações coletadas, de forma a evidenciar o desempenho do RabbitMQ no referido cenário.
Este cenário foi criado para validar a infraestrutura (cluster, imagem Docker) e contemplou apenas um deployment de producer e um deployment de consumer.
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
2 Gb | 1 | / | 800 Mb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | PRODUCERS | CONSUMERS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | SIZE |
---|---|---|---|---|---|---|
Producer-1 | 10 | 0 | perf-test-%02d | 1 | 10 | 3000 |
Consumer-1 | 0 | 10 | perf-test-%02d | 1 | 10 | n/a |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer-1 | Threads por fila | Instâncias Consumer-1 | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
1 | 1 | 1 | 1 | 10 | Prod: 10 Cons: 10 | 1500 | 1400 | Houve crescente acumulo de mensagens nas filas, devido a taxa de produção ser maior que a de consumo. |
1 | 1 | 2 | 1 | 10 | Prod: 20 Cons: 10 | 1300 | 1300 | A quantidade de mensagens nas filas estabilizou. A taxa de consumo por thread diminuiu por conta da concorrência de 2 threads de consumo por fila. |
1 | 1 | 3 | 1 | 10 | Prod: 30 Cons: 10 | 1500 | 1600 | Redução gradual de mensagens nas filas. Com 3 threads por fila, a taxa de consumo teve nova redução, mas ainda sim foi possível superar a taxa de produção e diminuir a quantidade de mensagens nas filas. |
Considerações:
Cenário configurado para testar alta demanda de mensagens em múltiplas filas.
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
2 Gb | 1 | / | 800 Mb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | PRODUCERS | CONSUMERS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | SIZE |
---|---|---|---|---|---|---|
Producer-1 | 10 | 0 | perf-test-%02d | 1 | 10 | 3000 |
Producer-2 | 11 | 20 | ||||
Producer-3 | 21 | 30 | ||||
Producer-4 | 31 | 40 | ||||
Producer-5 | 41 | 50 | ||||
Consumer-1 | 0 | 10 | perf-test-%02d | 1 | 10 | n/a |
Consumer-2 | 11 | 20 | ||||
Consumer-3 | 21 | 30 | ||||
Consumer-4 | 31 | 40 | ||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 (1 por deployment) | 1 | 5 (1 por deployment) | 1 | 50 (10 por deployment) | Prod: 50 Cons: 50 | 9000 | 6000 | O broker sofreu sobrecarga de memória e os nós reiniciaram várias vezes. |
1 (producer-1) | 1 | 1 (consumer-1) | 1 | 10 (producer-1) | Prod: 10 Cons: 10 | 3000 | 2700 | O broker estabilizou, com mensagens acumulando-se gradualmente nas filas. |
2 (producer 1 e 2) | 1 | 1 (consumer-1) | 1 | 20 (producer-1 e 2) | Prod: 20 Cons: 10 | 3000 | 2700 | Os nós reiniciaram na tentativa de subir o producer-2. Foi atingido o limite de memória devido acumulo de mensagens nas filas do producer-2, já que não havia consumidor ativo para elas. |
2 (producer-1 e 2) | 1 | 2 (consumer-1 e 2) | 1 | 20 (producer-1 e 2) | Prod: 20 Cons: 20 | 5000 | 4500 | Após reiniciar, os nós conseguiram acomodar os producers e consumers. |
2 (producer 1 e 2) | 1 | 3 (consumer 1 a 3) | 1 | 30 (consumer 1 a 3) | Prod: 20 Cons: 30 | 5000 | 4500 | Lentidão no broker para criar as filas correspondentes ao consumer-3. A intenção seria subir o producer-3 após todas as filas estarem disponíveis no RabbitMQ. |
2 (producer 1 e 2) | 1 | 5 (consumer 1 a 5) | 1 | 50 (consumer 1 a 5) | Prod: 20 Cons: 50 | 5000 | 4500 | Um dos nós reiniciou. O limite de memória (watermark) foi superado frequentemente. O broker ficou extremamente lento para responder a interface de gerenciamento (management UI), que estava solicitando refresh a cada 10 segundo. |
Considerações:
Cenário configurado para testar alta demanda de mensagens em múltiplas filas, com variação de tamanho e taxa de produção de mensagens:
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
2 Gb | 1 | / | 800 Mb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | PRODUCERS | CONSUMERS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|
Producer-1 | 10 | 0 | perf-test-%02d | 1 | 10 | 3000:60, 1000:120, 4000:60, 500:300 | 300:60, 1000:120, 3000:60, 500:300 |
Producer-2 | 11 | 20 | |||||
Producer-3 | 21 | 30 | |||||
Producer-4 | 31 | 40 | |||||
Producer-5 | 41 | 50 | |||||
Consumer-1 | 0 | 10 | perf-test-%02d | 1 | 10 | n/a | n/a |
Consumer-2 | 11 | 20 | |||||
Consumer-3 | 21 | 30 | |||||
Consumer-4 | 31 | 40 | |||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
1 (producer-1) | 1 | 1 (consumer-1) | 1 | 10 | Prod: 10 Cons: 20 | 2000 | 2000 | A quantidade de mensagens nas filas se manteve baixa. A taxa de produção variável gerou uma restrição nos produtores, que agora devem seguir os valores parametrizados. |
2 (producer 1 e 2) | 1 | 2 (consumer 1 e 2) | 1 | 20 | Prod: 20 Cons: 20 | 4000 | 4000 | Broker estável com pouca quantidade de mensagens acumuladas nas filas. |
5 (producer 1 a 5) | 1 | 5 (consumer 1 a 5) | 1 | 50 | Prod: 50 Cons: 50 | 9300 | 8900 | Houve queda dos nós do broker. Só foi possível subir todas as 5 instâncias producer após subir as 5 instâncias consumer. Cada novo producer adicionado gerava pico de memória no broker, excedendo o watermark máximo (800 Mb). Crescimento gradual das mensagens acumuladas na fila. |
5 (producer 1 a 5) | 1 | 10 (2 x consumers 1 a 5) | 2 | 50 | Prod: 50 Cons: 100 | 9100 | 9000 | Alguns minutos depois de estabilizar o broker com os 5 producers e 10 consumers, as mensagens acumuladas nas filas param de crescer. Havia cerca de 1 milhão de mensagens nas filas, com um consumo de memória em torno de 600 Mb em cada nó. |
5 (producer 1 a 5) | 1 | 15 (3 x consumers 1 a 5) | 3 | 50 | Prod: 50 Cons: 150 | 9100 | 9800 | Redução gradual das mensagens acumuladas nas filas. |
Considerações:
Cenário configurado para testar demanda reduzida de mensagens (1/10 dos valores do cenário anterior) em múltiplas filas, com variação de tamanho e taxa de produção de mensagens:
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
2 Gb | 1 | / | 800 Mb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | PRODUCERS | CONSUMERS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|
Producer-1 | 10 | 0 | perf-test-%02d | 1 | 10 | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | 11 | 20 | |||||
Producer-3 | 21 | 30 | |||||
Producer-4 | 31 | 40 | |||||
Producer-5 | 41 | 50 | |||||
Consumer-1 | 0 | 10 | perf-test-%02d | 1 | 10 | n/a | n/a |
Consumer-2 | 11 | 20 | |||||
Consumer-3 | 21 | 30 | |||||
Consumer-4 | 31 | 40 | |||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 (producer-1 a 5) | 1 | 5 (consumer-1 a 5) | 1 | 50 | Prod: 50 Cons: 50 | 2500 | 2400 | Com taxa menor na produção de mensagens, as instâncias dos produtores criaram as filas mais rápido que nos cenários anteriores. Os consumidores também conectaram mais rápido. Ocorreu acumulo de mensagens nas filas, mas em velocidade menor que nos cenários anteriores, devido a redução da taxa. Ao longo de uma noite inteira de funcionamento, devido o acumulo de mensagens, os nós reiniciaram cerca de 4 vezes cada. |
5 (producer 1 a 5) | 1 | 10 (2 x consumer 1 a 5) | 2 | 50 | Prod: 50 Cons: 100 | 2500 | 3500 | Houve um ligeiro aumento da quantidade de mensagens na fila assim que as 5 novas instâncias de consumidores foi iniciada. Parece que o broker reduziu a entrega para gerenciar as novas conexões. A performance geral do consumo não dobrou por conta da concorrência de consumidores nas filas (2 consumidores por fila). Constatou-se lentidão na utilização do Management UI, parametrizado para fazer refresh a cada 10 segundos. |
Considerações:
Cenário configurado para testar o uso de múltiplos vhosts, mantendo-se a demanda reduzida de mensagens (1/10 dos valores do cenário anterior) em múltiplas filas, com variação de tamanho e taxa de produção de mensagens:
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
2 Gb | 1 | /, app1, app2 | 800 Mb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | Vhost | PRODUCERS | CONSUMERS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|---|
Producer-1 | / | 10 | 0 | perf-test-%02d | 1 | 10 | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | app1 | 11 | 20 | |||||
Producer-3 | 21 | 30 | ||||||
Producer-4 | app2 | 31 | 40 | |||||
Producer-5 | 41 | 50 | ||||||
Consumer-1 | / | 0 | 10 | perf-test-%02d | 1 | 10 | n/a | n/a |
Consumer-2 | app1 | 11 | 20 | |||||
Consumer-3 | 21 | 30 | ||||||
Consumer-4 | app2 | 31 | 40 | |||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 (producer-1 a 5) | 1 | 5 (consumer-1 a 5) | 1 | 50 | Prod: 50 Cons: 50 | 2500 | 2400 | Houve queda dos brokers devido acúmulo de mensagens nas filas. |
5 (producer 1 a 5) | 1 | 10 (2 x consumer 1 a 5) | 2 | 50 | Prod: 50 Cons: 100 | 2500 | 3500 | A performance geral do consumo não dobrou por conta da concorrência de consumidores nas filas (2 consumidores por fila). Constatou-se lentidão na utilização do Management UI, parametrizado para fazer refresh a cada 10 segundos. |
Considerações:
Cenário idêntico ao anterior, mas com aumento de memória e CPU nos nós (ver a seguir os novos valores):
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
4 Gb | 2 | /, app1, app2 | 1,5 Gb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | Vhost | PRODUCERS | CONSUMERS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|---|
Producer-1 | / | 10 | 0 | perf-test-%02d | 1 | 10 | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | app1 | 11 | 20 | |||||
Producer-3 | 21 | 30 | ||||||
Producer-4 | app2 | 31 | 40 | |||||
Producer-5 | 41 | 50 | ||||||
Consumer-1 | / | 0 | 10 | perf-test-%02d | 1 | 10 | n/a | n/a |
Consumer-2 | app1 | 11 | 20 | |||||
Consumer-3 | 21 | 30 | ||||||
Consumer-4 | app2 | 31 | 40 | |||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 (producer-1 a 5) | 1 | 5 (consumer-1 a 5) | 1 | 50 | Prod: 50 Cons: 50 | 2500 | 2400 | Houve queda dos brokers devido acúmulo de mensagens nas filas. |
5 (producer 1 a 5) | 1 | 10 (2 x consumer 1 a 5) | 2 | 50 | Prod: 50 Cons: 100 | 2500 | 3500 | Ainda houve queda dos brokers, porem os níveis de consumo de memória ficaram abaixo do watermark máximo. Percebeu-se uma performance extremamente baixa do Management UI. |
Considerações:
Cenário idêntico ao anterior, com ajuste das configurações do deployment do RabbitMQ no Kubernetes. O ajuste consistiu em alterar o período de verificação da saúde do nó de 10 segundos para 30 segundos, e o tempo para timeout foi ampliado de 5 segundos para 10 segundos:
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
4 Gb | 2 | /, app1, app2 | 1,5 Gb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | Vhost | PRODUCERS | CONSUMERS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|---|
Producer-1 | / | 10 | 0 | perf-test-%02d | 1 | 10 | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | app1 | 11 | 20 | |||||
Producer-3 | 21 | 30 | ||||||
Producer-4 | app2 | 31 | 40 | |||||
Producer-5 | 41 | 50 | ||||||
Consumer-1 | / | 0 | 10 | perf-test-%02d | 1 | 10 | n/a | n/a |
Consumer-2 | app1 | 11 | 20 | |||||
Consumer-3 | 21 | 30 | ||||||
Consumer-4 | app2 | 31 | 40 | |||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 (producer-1 a 5) | 1 | 5 (consumer-1 a 5) | 1 | 50 | Prod: 50 Cons: 50 | 2500 | 2500 | Não houve mais registro de queda dos nós. A quantidade de mensagens nas filas ficou estável e num patamar bem baixo, em torno de 100 mensagens. O refresh automático do Management UI foi desabilitado. |
Considerações:
Cenário baseado no anterior, com definição da quantidade máxima de mensagens em cada fila (x-max-length) em 10 mil mensagens. Neste cenário, será avaliado o comportamento do RabbitMQ quanto ao acumulo de mensagens quando as filas possuem tamanho máximo.
Declaração de filas no RabbitMQ
A declaração de uma fila deve ser consistente entre os consumers e producers. No caso de propriedades como x-max-length, elas devem ser informadas tanto no deployment dos consumers quanto no dos producers, do contrário o RabbitMQ rejeita a declaração da fila e aborta a conexão.
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
4 Gb | 2 | /, app1, app2 | 1,5 Gb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | Vhost | PRODUCERS | CONSUMERS | QUEUE_ARGS | QUEUE_PATTERN | QUEUE_PATTERN_FROM | QUEUE_PATTERN_TO | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|---|---|
Producer-1 | / | 10 | 0 | x-max-kength=10000 | perf-test-%02d | 1 | 10 | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | app1 | 11 | 20 | ||||||
Producer-3 | 21 | 30 | |||||||
Producer-4 | app2 | 31 | 40 | ||||||
Producer-5 | 41 | 50 | |||||||
Consumer-1 | / | 0 | 10 | x-max-length=10000 | perf-test-%02d | 1 | 10 | n/a | n/a |
Consumer-2 | app1 | 11 | 20 | ||||||
Consumer-3 | 21 | 30 | |||||||
Consumer-4 | app2 | 31 | 40 | ||||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 (producer-1 a 5) | 1 | Nenhuma | 0 | 50 | Prod: 50 Cons: 0 | 4200 | 0 | As mensagens enfileiradas rapidamente atingiram o limite de 500 mil mensagens (50 filas x 10 mil mensagens), ficando estável neste patamar. Apesar disso, os produtores continuaram enviando mensagens, o que indica que as mensagens estavam sendo descartadas. O limite de memória chegou ao máximo (1,5 Gb) e um dos nós reiniciou. |
5 (producer 1 a 5) | 1 | 5 (consumers 1 a 5) | 1 | 50 | Prod: 50 Cons: 50 | 4200 | 3700 | A quantidade de mensagens enfileiradas baixou um pouco, mantendo-se em 243 mil mensagens. O consumo de memória ficou próximo do limite de 1,5 Gb. Lentidão na resposta do Management UI (em torno de 2 minutos para atualizar a página). |
5 (producers 1 a 5) | 1 | 10 (2 x consumer 1 a 5) | 2 | 50 | Prod: 50 Cons: 100 | 2100 | 2700 | Com mais consumers que producers, as mensagens enfileiradas baixaram para 62 mil, aproximadamente. Consequentemente, a memória dos nós também reduziu. |
10 (2 x producer 1 a 5) | 2 | 10 (2 x consumer 1 a 5) | 2 | 50 | Prod: 100 Cons: 100 | 4300 | 3700 | Mensagens acumuladas voltaram a crescer. Lentidão extrema do Management UI. |
Considerações:
Cenário baseado no anterior, com definição da quantidade de mensagens obtidas por cada consumidor (prefetch count).
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
4 Gb | 2 | /, app1, app2 | 1,5 Gb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | Vhost | PRODUCERS | CONSUMERS | QUEUE_ARGS | QUEUE_PATTERN | QUEUE_ PATTERN_ FROM | QUEUE_ PATTERN_ TO | QOS | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|---|---|---|
Producer-1 | / | 10 | 0 | x-max-kength=10000 | perf-test-%02d | 1 | 10 | n/a | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | app1 | 11 | 20 | |||||||
Producer-3 | 21 | 30 | ||||||||
Producer-4 | app2 | 31 | 40 | |||||||
Producer-5 | 41 | 50 | ||||||||
Consumer-1 | / | 0 | 10 | x-max-length=10000 | perf-test-%02d | 1 | 10 | 200 | n/a | n/a |
Consumer-2 | app1 | 11 | 20 | |||||||
Consumer-3 | 21 | 30 | ||||||||
Consumer-4 | app2 | 31 | 40 | |||||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 | 1 | 5 | 1 | 50 | Prod: 50 Cons: 50 | 4500 | 3200 | Broker estável, com mensagens enfileiradas atingindo o limite de 250 mil. Para evitar estouro de memória, mais consumers foram iniciados. |
5 | 1 | 10 | 2 | 50 | Prod: 50 Cons: 100 | 2950 | 2750 | Broker estável. Mensagens enfileiradas: 71 mil. |
10 | 2 | 10 | 2 | 50 | Prod: 100 Cons: 100 | 5200 | 4800 | Broker estável. Mensagens enfileiradas: 174 mil. |
10 | 2 | 15 | 3 | 50 | Prod: 100 Cons: 150 | 5500 | 4800 | Broker estável. Mensagens enfileiradas: 62 mil. A redução na performance do consumo pode estar ligada a concorrência de threads na mesma fila. |
15 | 3 | 15 | 3 | 50 | Prod: 150 Cons: 150 | ? | ? | Broker operacional, mas Management UI não responde mais às solicitações. Por este motivo as últimas medições não foram coletadas. |
Considerações:
Cenário baseado no anterior, com ajuste da quantidade de mensagens obtidas por cada consumidor (prefetch count) e da quantidade máxima de mensagens nas filas (max length).
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPU | Vhosts | Memory Watermark |
4 Gb | 2 | /, app1, app2 | 1,5 Gb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | Vhost | PRODUCERS | CONSUMERS | QUEUE_ARGS | QUEUE_PATTERN | QUEUE_ PATTERN_ FROM | QUEUE_ PATTERN_ TO | QOS | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|---|---|---|
Producer-1 | / | 10 | 0 | x-max-kength=20000 | perf-test-%02d | 1 | 10 | n/a | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | app1 | 11 | 20 | |||||||
Producer-3 | 21 | 30 | ||||||||
Producer-4 | app2 | 31 | 40 | |||||||
Producer-5 | 41 | 50 | ||||||||
Consumer-1 | / | 0 | 10 | x-max-length=20000 | perf-test-%02d | 1 | 10 | 500 | n/a | n/a |
Consumer-2 | app1 | 11 | 20 | |||||||
Consumer-3 | 21 | 30 | ||||||||
Consumer-4 | app2 | 31 | 40 | |||||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 | 1 | 15 | 3 | 50 | Prod: 50 Cons: 150 | 1500 | 1600 | Broker estável, com mensagens enfileiradas em torno de 3 mil. Durante o período de execução, houveram variações na performance de consumo, superando muitas vezes a taxa de produção, o que permitiu a redução das mensagens enfileiradas. |
10 | 2 | 15 | 3 | 50 | Prod: 100 Cons: 150 | 2400 | 2100 | Broker estável, com aumento no acumulo de mensagens, apesar do número de consumers ser maior do que o de producers. Ultima medição registrou 100 mil mensagens enfileiradas. |
15 | 3 | 15 | 3 | 50 | Prod: 150 Cons: 150 | 3000 | 2700 | Broker estável, com mensagens enfileiradas batendo em 134 mil. |
Considerações:
Cenário idêntico ao anterior, com ajuste da memória e CPU disponíveis para os testes.
Nó do cluster | RabbitMQ | ||
---|---|---|---|
Memória | CPUs | Vhosts | Memory Watermark |
8 Gb | 4 | /, app1, app2 | 3,1 Gb |
Os parâmetros de deployment utilizados foram os seguintes:
Deployment | Vhost | PRODUCERS | CONSUMERS | QUEUE_ARGS | QUEUE_PATTERN | QUEUE_ PATTERN_ FROM | QUEUE_ PATTERN_ TO | QOS | VARIABLE_SIZE | VARIABLE_RATE |
---|---|---|---|---|---|---|---|---|---|---|
Producer-1 | / | 10 | 0 | x-max-kength=20000 | perf-test-%02d | 1 | 10 | n/a | 3000:60, 1000:120, 4000:60, 500:300 | 30:60, 100:120, 300:60, 50:300 |
Producer-2 | app1 | 11 | 20 | |||||||
Producer-3 | 21 | 30 | ||||||||
Producer-4 | app2 | 31 | 40 | |||||||
Producer-5 | 41 | 50 | ||||||||
Consumer-1 | / | 0 | 10 | x-max-length=20000 | perf-test-%02d | 1 | 10 | 500 | n/a | n/a |
Consumer-2 | app1 | 11 | 20 | |||||||
Consumer-3 | 21 | 30 | ||||||||
Consumer-4 | app2 | 31 | 40 | |||||||
Consumer-5 | 41 | 50 |
A tabela abaixo demonstra o incremento de produtores e consumidores e resultados obtidos.
Instâncias Producer | Threads por fila | Instâncias Consumer | Threads por fila | Qtde. Filas | Conexões | Mensagens produzidas por segundo (média) | Mensagens consumidas por segundo (média) | Observações |
---|---|---|---|---|---|---|---|---|
5 | 1 | 15 | 3 | 50 | Prod: 50 Cons: 150 | 3600 | 3600 | Broker estável, mensagens enfileiradas em torno de 250. Management UI respondendo no tempo às requisições. |
10 | 2 | 15 | 3 | 50 | Prod: 100 Cons: 150 | 3250 | 3250 | Broker estável, mensagens enfileiradas em torno de 500. Management UI respondendo. |
15 | 3 | 15 | 3 | 50 | Prod: 150 Cons: 150 | 8300 | 9400 | Mensagens enfileiradas: 77 mil. Management UI extremamente lento. |
15 | 3 | 25 | 5 | 50 | Prod: 150 Cons: 250 | 6100 | 5500 | Os nós reiniciaram. Reiniciando testes com nova estratégia de adição de agentes (consumers e producers). |
5 | 1 | 10 | 2 | 50 | Prod: 50 Cons: 100 | 1500 | 1500 | Broker estável, Management UI respondendo. Mensagens enfileiradas: 11. A partir deste ponto, adotou-se a estratégia de adicionar gradualmente os agentes, colocando mais consumers que producers para evitar o aumento repentino de mensagens enfileiradas. |
10 | 2 | 15 | 3 | 50 | Prod: 100 Cons: 150 | 7000 | 7200 | Broker estável, Management UI respondendo. Mensagens enfileiradas: 11 mil. |
15 | 3 | 20 | 4 | 50 | Prod: 150 Cons: 200 | 6800 | 6700 | Broker estável, Management UI respondendo. Mensagens enfileiradas: 10 mil. |
15 | 3 | 25 | 5 | 50 | Prod: 150 Cons: 250 | 7000 | 7500 | Broker estável, Management UI respondendo. Mensagens enfileiradas: 96 mil. No início dos testes, foi nesta situação que os nós reiniciaram. |
20 | 4 | 30 | 6 | 50 | Prod: 200 Cons: 300 | 3000 | 12000 | Broker estável. Mensagens enfileiradas: 44 mil Memória: 800 Mb em cada nós. Management UI parou de responder aqui. |
25 | 5 | 30 | 6 | 50 | Prod: 250 Cons: 300 | ? | ? | Coleta por APIs não gerou resposta. O limite de memória foi excedido e os nós reiniciaram. |
Considerações:
Com base em todos os testes realizados acima é possível concluir que:
Por fim, considerando os resultados do estudo, arriscamos fazer as indicações de uso conforme abaixo, a título de referência, visando estabilidade do broker e margem para eventuais picos de carga:
Memória | CPU | Indicação de uso |
---|---|---|
2 Gb | 1 | Até 1000 msg/seg 50 produtores 100 consumidores |
4 Gb | 2 | Até 3000 msg/seg 100 produtores 150 consumidores |
8 Gb | 4 | Até 5000 msg/seg 200 produtores 250 consumidores |
Ferramenta de teste de carga perf-test - https://rabbitmq.github.io/rabbitmq-perf-test/stable/htmlsingle/
Manual do RabbitMQ:
Getting started with RabbitMQ and CloudAMQP - https://www.cloudamqp.com/rabbitmq_ebook.html
Elaboração |
|
Apresentação |
|
Implementação | Não se aplica |
Issue JIRA | Não se aplica |