Compartilhar via

Teste de desempenho com o Redis gerenciado do Azure (versão prévia)

  • 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 parâmetro de comparação do Redis. Duas das ferramentas mais populares são redis-benchmark e memtier-benchmark. Este artigo se concentra no memtier_benchmark, muitas vezes chamado de memtier.

Como usar o utilitário memtier_benchmark

  1. Instale o memtier em uma VMs (máquinas virtuais) 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 VM (máquina virtual) cliente usada para teste deve estar na mesma região que sua instância do AMR (Redis gerenciado do Azure).

  3. 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.

  4. Configure o isolamento de rede e as configurações de firewall da VM para garantir que a VM cliente consiga acessar sua instância do Redis gerenciado do Azure.

  5. Se você estiver usando O TLS/SSL na instância de cache, será necessário adicionar os parâmetros --tls e --tls-skip-verify ao comando memtier_benchmark.

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

  7. Em todas as instâncias do Redis gerenciado do Azure usando a política de cluster do OSS, é necessário adicionar o parâmetro --cluster-mode ao comando memtier. As instâncias do AMR usando 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 do shell da VM. Para obter instruções sobre como configurar e executar a ferramenta, consulte a Documentação do Memtier.

Recomendações de parâmetros de comparação

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

  • Escalar verticalmente para memória maiores também adiciona mais vCPUs, aumentando o desempenho. No entanto, escalar verticalmente para memória maiores normalmente é menos eficaz do que usar uma camada com mais desempenho. Consulte Camadas e SKUs em um relance para obter um detalhamento das vCPUs disponíveis para cada tamanho e camada.

  • O parâmetro de comparação da camada Otimizada para 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 quase são tão rápidas quanto outras instâncias do Redis gerenciado do Azure, mas as chaves no disco flash NVMe são mais lentas. Como o camada Otimizada para Flash coloca de forma inteligente as chaves mais usadas na DRAM, certifique-se de que a configuração de parâmetro de comparação corresponda ao uso real esperado.

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

  • É essencial primeiro preencher a instância do Redis com dados antes de aplicar o parâmetro de comparação. A aplicação do parâmetro de comparação 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 no parâmetro de comparação. O uso de muitas conexões começa a degradar o desempenho do cache. O uso de poucas conexões não demonstra o desempenho total do cache. É recomendável configurar o número de conexões com base nas necessidades reais do 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 no teste 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.

Exemplos de memtier_benchmark

Observação

Este exemplo mostra a aplicação de parâmetro de comparação em uma instância de Computação otimizada X3 usando a política de cluster e o TLS de OSS.

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 de maneira mais precisa as condições do mundo real. O parâmetro {number-of-keys} deve ser determinado pelo tamanho da instância do AMR e pelo tamanho de cada chave. Uma boa regra prática é preencher a instância deixando-a cerca de 75% completa, contando com os buffers. Você pode usar esta fórmula: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Por exemplo, se você estiver aplicando o parâmetro de comparação em uma instância de Computação otimizada X3, usando tamanhos de chave de 1.024 bytes, conforme 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 sinalizadores --tls, --tls-skip-verify e --cluster-mode. Você não precisará deles se estiver usando o Redis gerenciado do Azure no modo não TLS ou se estiver usando a Política de cluster Enterprise, respectivamente.

Para testar a taxa de transferência: esse comando testa solicitações GET em pipeline com carga de 1 mil. Use este comando para testar a taxa de transferência de leitura esperada da instância de cache. Este exemplo considera que você esta usando o TLS e a política de cluster do OSS. O parâmetro --key-pattern=R:R garante que as chaves sejam acessadas de maneira aleatória, aumentando o realismo do parâmetro de comparação. 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 parâmetro de comparação 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 Redis gerenciado do Azure. Usamos memtier_benchmark de uma VM da IaaS do Azure no ponto de extremidade do Redis gerenciado do Azure, utilizando os comandos memtier mostrados na seção Exemplos de memtier_benchmark. 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. O desempenho no mundo real varia de acordo com a configuração e os comandos do Redis. Esses números são fornecidos como um ponto de referência, não uma garantia.

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. Você pode obter resultados melhores ou diferentes na prática, especialmente na largura de banda de rede.

O Redis gerenciado do Azure oferece uma escolha 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 a seçãoClustering.

Os parâmetros de comparação para ambas as políticas de cluster são mostrados nas tabelas a seguir. Para a tabela de política de cluster do OSS, são fornecidas duas configurações de aplicação de parâmetro de comparação:

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

Os segundo parâmetro de comparação é fornecido porque 300 conexões não são suficientes para demonstrar totalmente o desempenho das instâncias de cache maiores.

Confira a seguir a taxa de transferência em operações GET por segundo em carga de 1 KB para instâncias do AMR junto ao número de conexões de cliente usadas para aplicar o parâmetro de comparação. Todos os números foram computados para instâncias do AMR com conexões SSL e a largura de banda de rede é registrada em Mbps.

Política de Cluster de OSS

Tamanho em GB vCPU/Rede BW/Otimizado para memória vCPU/Rede BW/Balanceada vCPU/Rede 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 Enterprise

Tamanho em GB vCPU/Rede BW/Otimizado para memória vCPU/Rede BW/Balanceada vCPU/Rede 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