Testes de desempenho com o Azure Managed Redis

Aplica-se a: ✅ Azure Managed Redis

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

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.
A máquina virtual (VM) cliente usada para teste deve estar na mesma região que sua instância do Azure Managed Redis (AMR).
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 de VM para garantir que a VM cliente possa acessar sua instância do Azure Managed Redis.
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.
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.
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.
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 Tiers e SKUs num olharpara uma análise detalhada dos vCPUs disponíveis para cada tamanho e nível.
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

Observação

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

Observação

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

A tabela abaixo mostra a taxa de transferência ideal que observamos ao testar vários tamanhos de instâncias do Azure Managed Redis com uma carga de trabalho de todos os comandos de leitura e carga útil de 1KB. A carga de trabalho é a mesma em todos os SKUs, exceto para a contagem de conexões (ou seja, threads e clientes diferentes, conforme exigido pelo memtier_benchmark). A contagem de conexões é escolhida por SKU para aproveitar a instância do Azure Managed Redis de forma otimizada. 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. O desempenho pode variar por vários motivos, como contagem de conexões diferentes, tamanho da carga útil, comandos que são executados, etc.

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 um hardware de cache de uma geração particular em uma única região. Você pode ver resultados 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, especialmente quando você precisa de alto desempenho. Para obter mais informações, consulte Clustering.

Tamanho em GB	Solicitações GET por segundo para Memória Otimizada	Solicitações GET por segundo para Balanceado	Solicitações GET por segundo para computação otimizada
0,5	-	120 000	-
1	-	120 000	-
3	-	230,000	480.000
6	-	230,000	480.000
12	230,000	480.000	810,000
24	480.000	810,000	1,600,000
60	810,000	1,500,000	2,000,000
cento e vinte	1,500,000	2,000,000	2,900,000

A tabela a seguir lista a contagem de conexões em termos da contagem de threads de memtier_benchmark e da contagem de clientes usadas para produzir os números de taxa de transferência. Como mencionado acima, alterar a contagem de conexões pode resultar em desempenho variável.

Tamanho em GB	Contagem de clientes/threads/conexões para memória otimizada	Contagem de clientes, threads e conexões para balanceamento	Contagem de Clientes/Threads/Conexões para Otimização Computacional
0,5	-	10/4/40	-
1	-	10/4/40	-
3	-	10/4/40	10/8/80
6	-	10/4/40	10/8/80
12	10/4/40	10/8/80	10/16/160
24	10/8/80	10/16/160	20/16/320
60	10/16/160	20/16/320	20/32/640
cento e vinte	20/16/320	20/32/640	20/64/1280

Próximos passos

Comentários

Esta página foi útil?

Last updated on 2025-11-10