Compartilhar via

Testes de desempenho

  • Artigo

Testar o desempenho de uma instância do Redis pode ser uma tarefa complicada. O desempenho de uma instância do Redis pode variar com base em parâmetros como o número de clientes, o tamanho dos valores de dados e se o pipelining está sendo usado. Também pode haver uma compensação entre otimizar a taxa de transferência ou a latência.

Felizmente, existem várias ferramentas para facilitar o parâmetro de comparação do Redis. Duas das ferramentas mais populares são redis-benchmark e memtier-benchmark. Este artigo se concentra no redis-benchmark.

Como usar o utilitário do redis-benchmark

  1. Instale o servidor Redis de software livre em VMs (máquinas virtuais) cliente que você pode usar para teste. O utilitário do redis-benchmark é integrado à distribuição do Redis de código aberto. Siga a documentação do Redis para obter instruções sobre como instalar a imagem de código aberto.

  2. A VM cliente usada para teste deve estar na mesma região que sua instância de Cache do Azure para Redis.

  3. Verifique se a VM cliente que você usa tenha pelo menos a mesma quantidade de poder de processamento e largura de banda que a instância de cache que está sendo testada.

  4. Defina suas configurações de isolamento de rede e de firewall para garantir que a VM cliente possa acessar sua instância de Cache do Azure para Redis.

  5. Se você estiver usando TLS/SSL em sua instância de cache, precisará adicionar o parâmetro --tls ao seu comando do redis-benchmark ou usar um proxy como stunnel.

  6. Redis-benchmark usa a porta 6379 por padrão. Use o parâmetro -p para substituir essa configuração. Você precisa usar o -p, se estiver usando SSL/TLS (porta 6380) ou estiver usando a camada Enterprise (porta 10000).

  7. Se você estiver usando uma instância de Cache do Azure para Redis que usa clustering, será necessário adicionar o parâmetro --cluster ao seu comando redis-benchmark. Os caches de camada Enterprise que usam o clustering do Enterprise podem ser tratados como caches não clusterizados e não precisam dessa configuração.

  8. Inicie redis-benchmark a partir da CLI ou do shell da VM. Para obter instruções sobre como configurar e executar a ferramenta, confira a documentação do redis-benchmark e as seções de exemplos do redis-benchmark.

Recomendações de parâmetros de comparação

  • É importante não apenas testar o desempenho de seu cache sob condições de estabilidade. Teste, também, em condições de failover e meça a carga de CPU/servidor no cache durante esse período. Você pode iniciar um failover reiniciando o nó primário. Com os testes sob condições de failover, você pode ver como a taxa de transferência e a latência do aplicativo se comportam durante as condições de failover. O failover pode acontecer durante as atualizações ou um evento não planejado. O ideal é não ver o pico de carga da CPU/servidor ultrapassar 80%, mesmo durante um failover, pois isso pode afetar o desempenho.

  • Considere utilizar as instâncias do Cache do Azure para Redis de camadas Enterprise e Premium. Esses tamanhos de cache têm melhor latência e taxa de transferência de rede porque estão sendo executados em um hardware melhor.

  • A camada Enterprise geralmente tem o melhor desempenho, pois o Redis Enterprise permite que o processo principal do Redis utilize várias vCPUs. As camadas baseadas em Redis de código aberto, como Standard e Premium, podem utilizar apenas uma vCPU para o processo do Redis por fragmento.

  • O parâmetro de comparação da camada Enterprise Flash pode ser difícil porque algumas chaves são armazenadas na DRAM, enquanto outras são armazenadas em um disco flash NVMe. As chaves no parâmetro de comparação DRAM são quase tão rápidas quanto uma instância de camada Enterprise, mas as chaves no disco flash NVMe são mais lentas. Como o camada Enterprise Flash coloca de forma inteligente as chaves mais usadas na DRAM, certifique-se de que sua configuração de parâmetro de comparação corresponda ao uso real esperado. Considere usar o parâmetro -r para tornar aleatório quais chaves serão acessadas.

  • O uso de TLS/SSL diminui o desempenho da taxa de transferência, o que pode ser visto claramente no exemplo de dados de parâmetro de comparação nas tabelas a seguir.

  • Mesmo que um servidor Redis seja de uma única thread, escalar verticalmente tende a melhorar o desempenho da taxa de transferência. Os processos do sistema podem usar as vCPUs extras em vez de compartilhar a vCPU usada pelo processo do Redis. Escalar verticalmente é especialmente útil nas camadas Enterprise e Enterprise Flash porque o Redis Enterprise não está limitado a uma única thread.

  • No camada Premium, escalar horizontalmente, clustering, é normalmente recomendado antes de escalar verticalmente. O clustering permite que o servidor Redis use mais vCPUs fragmentando os dados. A taxa de transferência deve aumentar aproximadamente de forma linear ao adicionar fragmentos nesse caso.

  • Nos caches C0 e C1, você pode ver picos curtos na carga do servidor não causados por um aumento nas solicitações algumas vezes por dia enquanto a verificação de vírus está em execução nas VMs. Você vê uma latência maior para solicitações enquanto as verificações internas do Defender são executadas nessas camadas algumas vezes por dia. Os caches nas camadas C0 e C1 têm apenas um núcleo para multitarefa, dividindo o trabalho de serviço de verificação de vírus e solicitações Redis. Você pode reduzir o efeito escalando para uma oferta de camada superior com vários núcleos de CPU, como C2.

    O aumento do tamanho do cache nas camadas mais altas ajuda a resolver quaisquer preocupações de latência. Além disso, no nível de C2, você tem suporte para até 2.000 conexões de cliente.

Exemplos com redis-benchmark

Configuração do pré-teste: prepare a instância de cache com os dados necessários para o teste de latência e taxa de transferência:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Para testar a latência: teste as solicitações GET com conteúdo de mil:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Para testar a taxa de transferência: solicitações GET em pipeline com conteúdo de mil:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Para testar a taxa de transferência de um cache de camada Basic, Standard ou Premium usando TLS: solicitações GET em pipeline com carga útil de 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

Para testar a taxa de transferência de um cache Enterprise ou Enterprise Flash sem TLS usando o Modo de Cluster de OSS: solicitações GET em pipeline com carga útil de 1k:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --cluster

Exemplo de dados de parâmetro de comparação de desempenho

As tabelas a seguir mostram os valores máximos da taxa de transferência que foram observados ao testar vários tamanhos de caches Standard, Premium, Enterprise e Enterprise Flash. Usamos redis-benchmark e memtier-benchmark de uma VM iaaS do Azure no ponto de extremidade do Cache do Azure para Redis. Os números da taxa de transferência são apenas para comandos GET. Normalmente, os comandos SET têm uma taxa de transferência menor. Esses números são otimizados para taxa de transferência. A taxa de transferência do mundo real sob condições aceitáveis de latência pode ser menor.

Cuidado

Esses valores não são garantidos e não há SLA para esses números. É altamente recomendável que você execute seu próprio teste de desempenho para determinar o tamanho de cache correto para seu aplicativo. Esses números podem mudar à medida que postarmos resultados mais novos periodicamente.

Importante

A Microsoft atualiza periodicamente a VM subjacente usada em instâncias de cache. Isso pode alterar as características de desempenho de acordo com o cache e a região. Os exemplos de valores de parâmetro de comparação desta página refletem o hardware de cache de geração mais antiga em uma região individual. Talvez você observe resultados melhores ou diferentes na prática.

A seguinte configuração foi usada para avaliar o desempenho da taxa de transferência nas camadas Básica, Standard e Premium:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Parâmetros de comparação Redis de camada standard

Instância Tamanho vCPUs Largura de banda de rede esperada (Mbps) Solicitações GET por segundo sem SSL (tamanho do valor de 1 kB) Solicitações GET por segundo com SSL (tamanho do valor de 1 kB)
C0 250 MB Compartilhado 100 15,000 7\.500
C1 1 GB 1 500 38.000 20,720
C2 2,5 GB 2 500 41.000 37.000
C3 6 GB 4 1000 100.000 90.000
C4 13 GB 2 500 60.000 55.000
C5 26 GB 4 1,000 102.000 93.000
C6 53 GB 8 2\.000 126.000 120.000

Parâmetros de comparação Redis da camada premium

Instância Tamanho vCPUs Largura de banda de rede esperada (Mbps) Solicitações GET por segundo sem SSL (tamanho do valor de 1 kB) Solicitações GET por segundo com SSL (tamanho do valor de 1 kB)
P1 6 GB 2 1\.500 180,000 172.000
P2 13 GB 4 3\.000 350.000 341.000
P3 26 GB 4 3\.000 350.000 341.000
P4 53 GB 8 6\.000 400.000 373.000
P5 120 GB 32 6\.000 400.000 373.000

Importante

As instâncias P5 nas regiões Leste da China e Norte da China usam 20 núcleos, não 32 núcleos.

Camadas Enterprise e Enterprise Flash

As camadas Enterprise e Enterprise Flash fornecem uma opção de política de cluster: Enterprise e OSS. A política de cluster Enterprise é uma configuração mais simples que não exige que o cliente suporte o clustering. A política de cluster de OSS, por outro lado, usa o protocolo de cluster do Redis para dar suporte a taxas de transferência mais altas. Recomendamos o uso da política de cluster de OSS na maioria dos casos. Para obter mais informações, confira a seção Clustering. Os parâmetros de comparação para ambas as políticas de cluster são mostrados nas tabelas a seguir.

A seguinte configuração foi usada para avaliar o desempenho da taxa de transferência nas camadas Enterprise e Enterprise Flash:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32

Observação

Essa configuração é quase idêntica à usada para avaliar o desempenho das camadas Básica, Standard e Premium. A configuração anterior, no entanto, não utilizava por completo o maior desempenho de computação das camadas Enterprise. Solicitações e threads extras foram adicionados a essa configuração para demonstrar o desempenho completo.

Política de Cluster Enterprise
Instância Tamanho vCPUs Largura de banda de rede esperada (Mbps) GET solicitações por segundo sem SSL (tamanho do valor de 1 kB) GET solicitações por segundo com SSL (tamanho do valor de 1 kB)
E10 12 GB 4 4.000 300.000 207.000
E20 25 GB 4 4.000 680,000 480.000
E50 50 GB 8 8,000 1.200.000 900.000
E100 100 GB 16 10.000 1.700.000 1.650.000
F300 384 GB 8 3\.200 500.000 390,000
F700 715 GB 16 6.400 500.000 370.000
F1500 1455 GB 32 12.800 530,000 390,000
Política de Cluster de OSS
Instância Tamanho vCPUs Largura de banda de rede esperada (Mbps) GET solicitações por segundo sem SSL (tamanho do valor de 1 kB) GET solicitações por segundo com SSL (tamanho do valor de 1 kB)
E10 12 GB 4 4.000 1.400.000 1\.000.000
E20 25 GB 4 4.000 1.200.000 900.000
E50 50 GB 8 8,000 2.300.000 1.700.000
E100 100 GB 16 10.000 3.000.000 2.500.000
F300 384 GB 8 3\.200 1\.500.000 1.200.000
F700 715 GB 16 6.400 1.600.000 1.200.000
F1500 1455 GB 32 12.800 1.600.000 1.110.000

Camadas Enterprise e Enterprise Flash – Escaladas horizontalmente

Além de escalar verticalmente movendo-se para um tamanho de cache maior, você pode aumentar o desempenho escalando horizontalmente. Nas camadas Enterprise, a escala horizontal é chamada de aumento da capacidade da instância de cache. Por padrão, uma instância de cache tem capacidade para dois, ou seja, um nó primário e um nó de réplica. Uma instância de cache Enterprise com capacidade de quatro indica que a instância foi escalada horizontalmente por um fator de dois. Escalar horizontalmente fornece acesso a mais memória e vCPUs. Detalhes sobre quantas vCPUs são usadas pelo processo principal do Redis em cada tamanho de cache e capacidade podem ser encontrados na configuração de Fragmentação. Escalar horizontalmente é mais eficaz ao usar a política de cluster de OSS.

As tabelas a seguir mostram as solicitações de GET por segundo em diferentes capacidades, usando SSL e um tamanho de valor de 1 kB.

Escalando horizontalmente - política de cluster Enterprise
Instância Capacidade 2 Capacidade 4 Capacidade 6
E10 200.000 830.000 930.000
E20 480.000 710,000 950.000
E50 900.000 1.110.000 1.200.000
E100 1.600.000 1.120.000 1.200.000
Instância Capacidade 3 Capacidade 9
F300 390,000 640.000
F700 370.000 610,000
F1500 390,000 670.000
Escalando horizontalmente - política de cluster de OSS
Instância Capacidade 2 Capacidade 4 Capacidade 6
E10 1\.000.000 1.900.000 2.500.000
E20 900.000 1.700.000 2.300.000
E50 1.700.000 3.000.000 3.900.000
E100 2.500.000 4.400.000 4.900.000
Instância Capacidade 3 Capacidade 9
F300 1.200.000 2.600.000
F700 1.200.000 2.600.000
F1500 1.100.000 2.800.000

Próximas etapas