Testes de desempenho
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
Instale o servidor Redis de código aberto em uma VM cliente que você pode usar para teste. 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.
A VM cliente usada para teste deve estar na mesma região que sua instância do Cache do Azure para Redis.
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.
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.
Se você estiver usando TLS/SSL em sua instância de cache, precisará adicionar o
--tlsparâmetro ao comando redis-benchmark ou usar um proxy como stunnel.Redis-benchmarkusa a porta 6379 por padrão. Use o-pparâ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).Se você estiver usando uma instância do Cache Redis do Azure que usa clustering, precisará adicionar o
--clusterparâmetro ao comandoredis-benchmark. Os caches de camada corporativa que usam a política de clustering Enterprise podem ser tratados como caches não clusterizados e não precisam dessa configuração.Inicie
redis-benchmarka 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
-rparâ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. Para obter mais informações, consulte Práticas recomendadas da camada empresarial.
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.
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 a partir 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.
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
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.
Escalão 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 | 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 |
Escalão 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 on Enterprise. 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) | 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) |
|---|---|---|---|---|---|
| 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) | 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) |
|---|---|---|---|---|---|
| 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 página de práticas recomendadas de camadas Enterprise. A expansão é mais eficaz ao usar a diretiva de cluster OSS.
As tabelas a seguir mostram as solicitações GET 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 |