Partilhar 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 benchmarking do Redis. Duas das ferramentas mais populares são redis-benchmark e memtier-benchmark. Este artigo centra-se no redis-benchmark.

Como usar o utilitário redis-benchmark

  1. Instale o servidor Redis de código aberto em máquinas virtuais (VMs) cliente que você pode usar para testes. O utilitário redis-benchmark está integrado na distribuição 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 do Cache do Azure para Redis.

  3. Verifique se a VM cliente que você usa tem pelo menos tanta computação e largura de banda quanto a instância de cache que está sendo testada.

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

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

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

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

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

Recomendações de avaliação comparativa

  • É importante não apenas testar o desempenho do cache em condições de estado estacionário. Teste também em condições de failover e meça a carga da CPU/servidor no cache durante esse tempo. Você pode iniciar um failover reinicializando o nó primário. O teste em condições de failover permite que você veja a taxa de transferência e a latência do seu aplicativo durante as condições de failover. O failover pode acontecer durante atualizações ou durante um evento não planejado. Idealmente, você não quer ver o pico de carga da CPU/servidor para mais de 80%, mesmo durante um failover, pois isso pode afetar o desempenho.

  • Considere o uso do Cache do Azure de camada Enterprise e Premium para instâncias Redis. Esses tamanhos de cache têm melhor latência e taxa de transferência de rede porque são executados em hardware melhor.

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

  • O benchmarking 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 benchmark 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 a camada Enterprise Flash coloca de forma inteligente as chaves mais usadas no DRAM, certifique-se de que sua configuração de benchmark corresponda ao uso real esperado. Considere usar o -r parâmetro para aleatorizar quais chaves sã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 benchmarking nas tabelas a seguir.

  • Mesmo que um servidor Redis seja de thread único, o escalonamento 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 que está sendo usada pelo processo Redis. A expansão é especialmente útil nas camadas Enterprise e Enterprise Flash porque o Redis Enterprise não está limitado a um único thread.

  • Na camada Premium, normalmente recomenda-se o dimensionamento, o clustering, antes da expansão. O clustering permite que o servidor Redis use mais vCPUs fragmentando dados. A taxa de transferência deve aumentar aproximadamente linearmente ao adicionar fragmentos neste caso.

  • Nos caches C0 e C1 Standard, enquanto a verificação interna do Defender está sendo executada nas VMs, você pode ver pequenos picos na carga do servidor não causados por um aumento nas solicitações de cache. Você vê uma latência mais alta 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 único núcleo para multitarefa, dividindo o trabalho de atender às solicitações internas do Defender e do Redis. Você pode reduzir o efeito dimensionando para uma oferta de camada mais alta com vários núcleos de CPU, como C2.

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

Exemplos de Redis-benchmark

Configuração de 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 solicitações GET usando uma carga útil de 1k:

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 canalizadas com carga útil de 1k:

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 canalizadas 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 OSS: Solicitações GET canalizadas 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 benchmark de desempenho

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

Atenção

Esses valores não são garantidos e não há SLA para esses números. É altamente recomendável que você execute seus próprios testes de desempenho para determinar o tamanho de cache correto para seu aplicativo. Estes números podem mudar à medida que formos publicando resultados mais recentes periodicamente.

Importante

A Microsoft atualiza periodicamente a VM subjacente usada em instâncias de cache. Isso pode alterar as características de desempenho de cache para cache e de região para região. Os valores de benchmarking de exemplo nesta página refletem hardware de cache de geração mais antiga em uma única região. Você pode ver resultados melhores ou diferentes na prática.

A seguinte configuração foi usada para avaliar a taxa de transferência para as camadas Basic, Standard e Premium:

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

Benchmarks Redis de nível padrão

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 Partilhado 100 15 000 7500
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

Benchmarks Redis de nível 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 1500 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 6000 400,000 373,000
P5 120 GB 32 6000 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.

Níveis Enterprise & Enterprise Flash

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

A seguinte configuração foi usada para avaliar a taxa de transferência para as camadas flash Enterprise e Enterprise:

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

Nota

Essa configuração é quase idêntica à usada para comparar as camadas Basic, Standard e Premium. A configuração anterior, no entanto, não utilizava totalmente o maior desempenho de computação das camadas Enterprise. Solicitações e threads adicionais foram adicionados a essa configuração para demonstrar o desempenho completo.

Política de Cluster Empresarial
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 pedidos 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 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 pedidos 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

Enterprise & Enterprise Flash Tiers - Escalonado

Além de aumentar a escala movendo-se para um tamanho de cache maior, você pode aumentar o desempenho dimensionando-o. Nas camadas Enterprise, o dimensionamento é chamado de aumento da capacidade da instância de cache. Uma instância de cache por padrão tem capacidade de 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 dimensionada por um fator de dois. A expansão fornece acesso a mais memória e vCPUs. Detalhes sobre quantas vCPUs são usadas pelo processo Redis principal em cada tamanho e capacidade de cache podem ser encontrados na configuração Sharding. A expansão é mais eficaz ao usar a diretiva de cluster OSS.

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

Expansão - Política de cluster empresarial
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
Dimensionamento - política de cluster 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óximos passos