Compartir a través de

Pruebas de rendimiento con Azure Managed Redis (versión preliminar)

  • Artículo

Probar el rendimiento de una instancia de Redis puede ser una tarea complicada. El rendimiento de una instancia de Redis puede variar en función de parámetros como el número de clientes, el tamaño de los valores de datos y si se usa la canalización. También puede haber un equilibrio entre optimizar el rendimiento o la latencia.

Afortunadamente, existen varias herramientas para facilitar la realización de pruebas comparativas de Redis. Dos de las herramientas más populares son redis-benchmark y memtier-benchmark. Este artículo se centra en memtier_benchmark, a menudo denominado memtier.

Cómo usar la utilidad memtier_benchmark

  1. Instale memtier en un cliente de máquinas virtuales (VM) que pueda utilizar para realizar pruebas. Siga la documentación de Memtier para obtener instrucciones sobre cómo instalar la imagen de código abierto.

  2. La máquina virtual (VM) cliente utilizada para las pruebas debe estar en la misma región que su instancia de Azure Managed Redis (AMR).

  3. Asegúrese de que la VM cliente que use tenga al menos tantos procesos y ancho de banda como la instancia de caché que se está probando.

  4. Configure el aislamiento de la red y los ajustes del firewall de la máquina virtual para garantizar que la máquina virtual del cliente pueda acceder a su instancia de Azure Managed Redis.

  5. Si usa TLS/SSL en la instancia de caché, debe agregar los parámetros --tls y --tls-skip-verify al comando memtier_benchmark.

  6. memtier_benchmark usa el puerto 6379, de manera predeterminada. Use el parámetro -p 10000 para invalidar esta configuración, ya que AMR usa el puerto 10000 en su lugar.

  7. Para todas las instancias de Azure Managed Redis mediante la directiva de clúster de OSS, debe agregar el parámetro --cluster-mode al comando memtier. Las instancias de AMR que usan la directiva de clúster de Enterprise se pueden tratar como cachés no agrupadas y no necesitan esta configuración.

  8. Inicie memtier_benchmark desde la CLI o el shell de la máquina virtual. Para obtener instrucciones sobre cómo configurar y ejecutar la herramienta, consulte la documentación de Memtier.

Recomendaciones de pruebas comparativas

  • Si no obtiene el rendimiento que necesita, intente escalar verticalmente a un nivel más avanzado. El nivel equilibrado suele tener el doble de vCPUs que el nivel optimizado para memoria, y el nivel optimizado para proceso suele tener el doble de vCPUs que el nivel equilibrado. Dado que Azure Managed Redis se basa en Redis Enterprise en lugar de en Redis de la comunidad, el proceso principal de Redis puede usar varias vCPU. Como resultado, las instancias con más vCPU tienen un rendimiento significativamente mejor.

  • El escalado vertical a tamaños de memoria mayores también agrega más vCPU, lo que aumenta el rendimiento. Sin embargo, el escalado vertical a tamaños de memoria más grandes suele ser menos eficaz que usar un nivel de mayor rendimiento. Consulte Niveles y SKU de un vistazo para obtener un desglose detallado de las vCPU disponibles para cada tamaño y nivel.

  • Los bancos de prueba del nivel optimizado para Flash puede ser difícil porque algunas claves se almacenan en DRAM mientras que otras se almacenan en un disco flash NVMe. Las claves en DRAM son casi tan rápidas como otras instancias de Azure Managed Redis, pero las claves en el disco flash NVMe son más lentas. Dado que el nivel optimizado para Flash coloca de forma inteligente las claves más utilizadas en la DRAM, asegúrese de que la configuración de su banco de pruebas coincide con el uso real que espera.

  • El uso de TLS/SSL reduce el rendimiento, pero se recomienda encarecidamente como procedimiento recomendado de producción.

  • Es esencial rellenar primero la instancia de Redis con datos antes de realizar el banco de pruebas. El banco de pruebas con una caché vacía genera resultados mucho mejores de los que vería en la práctica.

  • El número de conexiones usadas tiene un efecto significativo en el banco de pruebas. El uso de demasiadas conexiones comienza a degradar el rendimiento de la memoria caché. El uso de muy pocas conexiones no demuestra todo el rendimiento de la caché. Recomendamos configurar el número de conexiones en función de las necesidades reales de su aplicación. Determine el número total de conexiones multiplicando el número de clientes por el número de subprocesos.

  • La configuración de canalización tiene un efecto significativo en las pruebas de rendimiento. Si establece la configuración de canalización para que sea mayor, verá más rendimiento, pero una latencia peor. Para obtener más información, consulte canalización.

ejemplos de memtier_benchmark

Nota:

En este ejemplo se muestra el banco de pruebas en una instancia X3 optimizada para proceso mediante la directiva de clúster del OSS y TLS.

Configuración previa a la prueba: prepare la instancia de caché con los datos necesarios para las pruebas. Cargar la instancia con datos garantiza que los resultados reflejen con mayor precisión las condiciones del mundo real. El parámetro {number-of-keys} debe estar determinado por el tamaño de su instancia AMR y el tamaño de cada clave. Una buena regla general es rellenar la instancia aproximadamente en un 75%, teniendo en cuenta los búferes. Puede usar esta fórmula: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Por ejemplo, si va a realizar un banco de pruebas en una instancia X3 optimizada para proceso, con tamaños de clave de 1024 bytes, como se muestra anteriormente, eso implica {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). El resultado es igual a aproximadamente 1 699 396 claves.

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:

En este ejemplo se usan las marcas --tls, --tls-skip-verify y --cluster-mode. No los necesita si usa Azure Managed Redis en modo sin TLS o si usa la directiva de clúster Enterprise, respectivamente.

Para probar el rendimiento: Para comprobar el rendimiento: Este comando prueba solicitudes GET canalizadas con una carga útil de 1000. Use este comando para probar cuánto rendimiento de lectura puede esperar de su instancia de caché. Este ejemplo asume que usa TLS y la directiva de clúster de OSS. El parámetro --key-pattern=R:R garantiza que se accede aleatoriamente a las claves, lo que aumenta el realismo del banco de pruebas. Esta prueba se ejecuta durante 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

Ejemplo de datos de pruebas comparativas de rendimiento

Las siguientes tablas muestran los valores máximos de rendimiento que se observaron al probar varios tamaños de instancias de Azure Managed Redis. Usamos memtier_benchmark de una máquina virtual de Azure IaaS en el punto de conexión de Azure Managed Redis, usando los comandos memtier que se muestran en la sección ejemplos de memtier_benchmark. Los números de rendimiento solo son para comandos GET. Normalmente, los comandos SET tienen un rendimiento menor. El rendimiento en el mundo real varía en función de la configuración y los comandos de Redis. Estos números se proporcionan como punto de referencia, no como garantía.

Precaución

Estos valores no se garantizan y no hay ningún SLA para estos números. Se recomienda encarecidamente que realice sus propias pruebas de rendimiento para determinar el tamaño de caché adecuado para la aplicación. Estas cifras pueden cambiar, puesto que se publican resultados más recientes de manera periódica.

Importante

Microsoft actualiza periódicamente la máquina virtual subyacente que se usa en las instancias de caché. Esto puede cambiar las características de rendimiento de una caché a otra y de una región a otra. Los valores de pruebas comparativas de ejemplo de esta página reflejan el hardware de caché de una generación anterior en una sola región. Es posible que en la práctica vea resultados mejores o diferentes, especialmente con el ancho de banda de la red.

Azure Managed Redis ofrece una opción de directiva de clúster: Enterprise y OSS. La directiva de clúster Enterprise es una configuración más sencilla que no requiere que el cliente admita la agrupación en clústeres. Por otro lado, la directiva de clúster del sistema operativo usa el protocolo de clúster de Redis para admitir un mayor rendimiento. Se recomienda usar la directiva de clúster del OSS en la mayoría de los casos. Para obtener más información, consulte agrupación en clústeres.

Las pruebas comparativas de ambas directivas de clúster se muestran en las tablas siguientes. Para la tabla de directivas de clúster de OSS, se proporcionan dos configuraciones de banco de pruebas:

  • 300 conexiones (50 clientes y 6 subprocesos)
  • 2500 conexiones (50 clientes y 50 subprocesos)

El segundo banco de pruebas se proporcionan porque 300 conexiones no son suficientes para demostrar completamente el rendimiento de las instancias de caché más grandes.

A continuación se muestra el rendimiento en operaciones GET por segundo con una carga útil de 1 kB para instancias de AMR junto con el número de conexiones de cliente utilizadas para el banco de pruebas. Todos los números se calcularon para las instancias de AMR con conexiones SSL y el ancho de banda de red se registra en Mbps.

La directiva de clúster de OSS

Tamaño en GB vCPU/Red BW/Optimizada para memoria vCPU/Red BW/Equilibrado vCPU/Red BW/Optimizado para proceso
1 - 2/5000/103 500 -
3 - 2/2000/104 500 4/10 000/221 100
6 - 2/2000/106 500 4/10 000/210 850
12 2/2000/106 000 4/4000/223 900 8/12 500/499 900
24 4/4000/227 800 8/8000/495 300 16/12 500/485 920
60 8/8000/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

Directiva de clúster de Enterprise

Tamaño en GB vCPU/Red BW/Optimizada para memoria vCPU/Red BW/Equilibrado vCPU/Red BW/Optimizado para proceso
1 - 2/5000/56 900 -
3 - 2/2000/56 900 4/10 000/118 900
6 - 2/2000/59 200 4/10 000/111 950
12 2/2000/55 800 4/4000/118 500 8/12 500/206 500
24 4/4000/122 000 8/8000/205 500 16/12 500/294 700
60 8/8000/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