Partilhar via

Testes de desempenho com o Azure Managed Redis (visualização)

  • 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 se concentra em memtier_benchmark, muitas vezes chamado de memtier.

Como usar o utilitário memtier_benchmark

  1. Instale o memtier em máquinas virtuais (VMs) cliente que você pode usar para teste. Siga a documentação do Memtier para obter instruções sobre como instalar a imagem de código aberto.

  2. A máquina virtual (VM) cliente usada para teste deve estar na mesma região que sua instância do Azure Managed Redis (AMR).

  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 de VM para garantir que a VM cliente possa acessar sua instância do Azure Managed Redis.

  5. Se você estiver usando TLS/SSL em sua instância de cache, precisará adicionar os --tls parâmetros e --tls-skip-verify ao comando memtier_benchmark.

  6. memtier_benchmark usa a porta 6379 por padrão. Use o parâmetro para substituir essa configuração, pois o AMR usa a -p 10000 porta 10000.

  7. Para todas as instâncias do Azure Managed Redis que usam a política de cluster OSS, você precisa adicionar o --cluster-mode parâmetro ao comando memtier. As instâncias AMR que usam a política de cluster Enterprise podem ser tratadas como caches não clusterizados e não precisam dessa configuração.

  8. Inicie memtier_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 Memtier.

Recomendações de avaliação comparativa

  • Se você não estiver obtendo o desempenho de que precisa, tente escalar para uma camada mais avançada. A camada Balanceada normalmente tem duas vezes mais vCPUs do que a camada Otimizada para memória, e a camada Otimizada para computação normalmente tem o dobro de vCPUs que a camada Balanceada. Como o Azure Managed Redis é baseado no Redis Enterprise em vez de no Redis da comunidade, o processo Redis principal é capaz de utilizar várias vCPUs. Como resultado, instâncias com mais vCPUs têm um desempenho de taxa de transferência significativamente melhor.

  • O dimensionamento para tamanhos de memória maiores também adiciona mais vCPUs, aumentando o desempenho. No entanto, o dimensionamento para tamanhos de memória maiores geralmente é menos eficaz do que usar uma camada de maior desempenho. Consulte Camadas e SKUs rapidamente para obter um detalhamento detalhado das vCPUs disponíveis para cada tamanho e camada.

  • O benchmarking da camada Flash Optimized 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 outras instâncias do Azure Managed Redis, mas as chaves no disco flash NVMe são mais lentas. Como a camada Flash Optimized coloca de forma inteligente as chaves mais usadas no DRAM, certifique-se de que sua configuração de benchmark corresponda ao uso real esperado.

  • O uso de TLS/SSL diminui o desempenho da taxa de transferência, mas é altamente recomendado como prática recomendada de produção.

  • É essencial primeiro preencher a instância do Redis com dados antes do benchmarking. O benchmarking em um cache vazio produz resultados muito melhores do que você veria na prática.

  • O número de conexões usadas tem um efeito significativo sobre o benchmark. O uso de muitas conexões começa a degradar o desempenho do cache. Usar poucas conexões não demonstra o desempenho total do cache. Recomendamos configurar o número de conexões com base nas necessidades reais do seu aplicativo. Você determina o número total de conexões multiplicando o número de clientes pelo número de threads.

  • A configuração do pipeline tem um efeito significativo nos testes de desempenho. Se você definir a configuração do pipeline para ser maior, verá mais taxa de transferência, mas latência pior. Para obter mais informações, consulte pipelining.

memtier_benchmark exemplos

Nota

Este exemplo mostra benchmarking em uma instância Compute Optimized X3 usando a política de cluster OSS e TLS.

Configuração de pré-teste: prepare a instância de cache com os dados necessários para o teste. Carregar a instância com dados garante que os resultados reflitam com mais precisão as condições do mundo real. O {number-of-keys} parâmetro deve ser determinado pelo tamanho da instância AMR e pelo tamanho de cada chave. Uma boa regra geral é preencher a instância aproximadamente 75% cheia, contabilizando os buffers. Você pode usar esta fórmula: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Por exemplo, se você estiver fazendo benchmarking em uma instância X3 otimizada para computação, usando tamanhos de chave de 1.024 bytes, como mostrado anteriormente, isso implica {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). O resultado equivale a aproximadamente 1.699.396 chaves.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 -data-size=1024 --tls --cluster-mode

Nota

Este exemplo usa os --tlssinalizadores , --tls-skip-verify, e --cluster-mode . Você não precisará deles se estiver usando o Azure Managed Redis no modo não-TLS ou se estiver usando a política de cluster Enterprise, respectivamente.

Para testar a taxa de transferência: este comando testa solicitações GET canalizadas com carga útil de 1k. Use este comando para testar a taxa de transferência de leitura esperada da instância de cache. Este exemplo pressupõe que você esteja usando TLS e a diretiva de cluster OSS. O --key-pattern=R:R parâmetro garante que as chaves sejam acessadas aleatoriamente, aumentando o realismo do benchmark. Este teste é executado por cinco minutos.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

Exemplo de dados de benchmark de desempenho

As tabelas a seguir mostram os valores máximos de taxa de transferência que foram observados durante o teste de vários tamanhos de instâncias do Azure Managed Redis. Usamos memtier_benchmark a partir de uma VM IaaS do Azure no ponto de extremidade Redis gerenciado do Azure, utilizando os comandos memtier mostrados na seção memtier_benchmark exemplos . 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. O desempenho no mundo real varia de acordo com a configuração e os comandos do Redis. Estes números são fornecidos como um ponto de referência, não como uma garantia.

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, especialmente com a largura de banda da rede.

O Azure Managed Redis oferece 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 uma taxa de transferência mais alta. 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. Para a tabela de políticas de cluster OSS, duas configurações de benchmarking são fornecidas:

  • 300 conexões (50 clientes e 6 threads)
  • 2.500 conexões (50 clientes e 50 threads)

Os segundos benchmarks são fornecidos porque 300 conexões não são suficientes para demonstrar completamente o desempenho das instâncias de cache maiores.

A seguir estão a taxa de transferência em operações GET por segundo em carga útil de 1 kB para instâncias AMR ao longo do número de conexões de cliente usadas para benchmarking. Todos os números foram calculados para instâncias AMR com conexões SSL e a largura de banda da rede é registrada em Mbps.

Política de cluster OSS

Tamanho em GB vCPU/Network BW/Memória otimizada vCPU/Rede BW/Balanceado vCPU/Network BW/Computação otimizada
1 - 2/5,000/103,500 -
3 - 2/2,000/104,500 4/10,000/221,100
6 - 2/2,000/106,500 4/10,000/210,850
12 2/2,000/106,000 4/4,000/223,900 8/12,500/499,900
24 4/4,000/227,800 8/8,000/495,300 16/12,500/485,920
60 8/8,000/496,000 16/10,000/476,500 32/16,000/454,200
120 16/10,000/476,200 32/16,000/462,200 64/28,000/463,800

Política de Cluster Empresarial

Tamanho em GB vCPU/Network BW/Memória otimizada vCPU/Rede BW/Balanceado vCPU/Network BW/Computação otimizada
1 - 2/5,000/56,900 -
3 - 2/2,000/56,900 4/10,000/118,900
6 - 2/2,000/59,200 4/10,000/111,950
12 2/2,000/55,800 4/4,000/118,500 8/12,500/206,500
24 4/4,000/122,000 8/8,000/205,500 16/12,500/294,700
60 8/8,000/208,100 16/10,000/293,400 32/16,000/441,400
120 16/10,000/285,600 32/16,000/451,700 64/28,000/516,200