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 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
Instale o servidor Redis de código aberto em uma VM 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.
A VM cliente usada para teste deve estar na mesma região que sua instância de Cache do Azure para Redis.
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.
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.
Se você estiver usando TLS/SSL em sua instância de cache, precisará adicionar o parâmetro
--tlsao seu comando do redis-benchmark ou usar um proxy como stunnel.Redis-benchmarkusa a porta 6379 por padrão. Use o parâmetro-ppara substituir essa configuração. Você precisa usar o-p, se estiver usando SSL/TLS (porta 6380) ou estiver usando a camada Enterprise (porta 10000).Se você estiver usando uma instância de Cache do Azure para Redis que usa clustering, será necessário adicionar o parâmetro
--clusterao seu comandoredis-benchmark. Os caches de camada Enterprise 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 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
-rpara 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. Para obter mais informações, confira as melhores práticas da camada Enterprise.
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.
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 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 de latência aceitáveis pode ser menor.
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
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.
Camada 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 | 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 |
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 o Clustering no Enterprise. 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) | 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 de 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 |
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 e capacidade de cache podem ser encontrados na página de melhores práticas das camadas Enterprise. Escalar horizontalmente é mais eficaz ao usar a política de cluster de 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.
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 |