Pruebas de rendimiento con Azure Managed Redis

Se aplica a: ✅ Azure Managed Redis

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

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.
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).
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.
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.
Si usa TLS/SSL en la instancia de caché, debe agregar los parámetros --tls y --tls-skip-verify al comando memtier_benchmark.
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.
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.
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 vistazopara 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 es necesario si usa Azure Managed Redis en modo no TLS o si usa la Directiva de clúster de 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

En la tabla siguiente se muestra el rendimiento óptimo que observamos al probar varios tamaños de instancias de Redis administradas de Azure con una carga de trabajo de todos los comandos de lectura y carga de 1 KB. La carga de trabajo es la misma en todas las SKU, excepto en el recuento de conexiones (es decir, un número diferente de subprocesos y clientes según sea necesario en memtier_benchmark). El recuento de conexiones se elige por SKU para aprovechar la instancia de Azure Managed Redis de forma óptima. 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. El rendimiento puede variar por varios motivos, como el recuento de conexiones, el tamaño de la carga, los comandos que se ejecutan, etc.

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 un hardware de caché de generación determinado en una sola región. Es posible que vea resultados diferentes en la práctica, especialmente con el ancho de banda de 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 sistema operativo en la mayoría de los casos, especialmente cuando se requiere un alto rendimiento. Para obtener más información, consulte agrupación en clústeres.

Tamaño en GB	Solicitudes GET por segundo para Memoria Optimizada	Solicitudes GET por segundo para Equilibrado	Solicitudes GET por segundo para Compute Optimized
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
120	1 500 000	2 000 000	2 900 000

En la tabla siguiente se muestra el recuento de conexiones en lo que respecta al número de hilos de memtier_benchmark y al número de clientes utilizado para generar los valores de rendimiento. Como se mencionó anteriormente, cambiar el recuento de conexiones podría dar lugar a un rendimiento variable.

Tamaño en GB	Clientes, subprocesos y recuento de conexiones para memoria optimizada	Clientes, subprocesos y recuento de conexiones para equilibrado	Clientes, subprocesos y recuento de conexiones para proceso optimizado
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
120	20/16/320	20/32/640	20/64/1280

Pasos siguientes

Comentarios

¿Le resultó útil esta página?

Last updated on 2025-11-10