Compartir a través de

Pruebas de rendimiento

  • 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 redis-benchmark.

Uso de la utilidad redis-benchmark

  1. Instale el servidor Redis de código abierto en una máquina virtual (VM) cliente que puede usar para realizar pruebas. La utilidad redis-benchmark está integrada en la distribución Redis de código abierto. Siga la documentación de Redis para obtener instrucciones sobre cómo instalar la imagen de código abierto.

  2. El cliente para pruebas de máquina virtual debe estar en la misma región que la instancia de Azure Cache for Redis.

  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. Establezca la configuración de firewall y aislamiento de red para asegurarse de que la máquina virtual cliente pueda acceder a la instancia de Azure Cache for Redis.

  5. Si usa TLS/SSL en la instancia de caché, debe agregar el --tls parámetro al comando redis-benchmark o usar un proxy como stunnel.

  6. Redis-benchmark usa el puerto 6379, de manera predeterminada. Use el parámetro -p para invalidar esta configuración. Debe usar -p, si usa SSL/TLS (puerto 6380) o usa el nivel Enterprise (puerto 10000).

  7. Si usa una instancia de Azure Cache for Redis que usa la agrupación en clústeres, debe agregar el parámetro --cluster al comando redis-benchmark. Las memorias caché de nivel empresarial que usan el Agrupación en clústeres se pueden tratar como cachés no agrupadas y no necesitan esta configuración.

  8. Inicie redis-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 redis-benchmark y las secciones de ejemplos de redis-benchmark.

Recomendaciones de pruebas comparativas

  • Es importante no solo probar el rendimiento de la caché en condiciones de estado estable. Realice pruebas también en condiciones de conmutación por error y mida la carga de la CPU o el servidor en la caché durante ese tiempo. Puede iniciar una conmutación por error reiniciando el nodo principal. Las pruebas en condiciones de conmutación por error permiten ver el rendimiento y la latencia de la aplicación durante condiciones de conmutación por error. La conmutación por error puede producirse durante las actualizaciones o durante un evento no planeado. Idealmente, no es deseable ver el pico de carga de CPU o servidor a más de un 80 % incluso durante una conmutación por error, ya que esto puede afectar al rendimiento.

  • Considere la posibilidad de usar instancias de Azure Cache for Redis de nivel Enterprise y Premium. Estos tamaños de caché tendrán mejor latencia de red y rendimiento porque se ejecutan en un mejor hardware.

  • El nivel Enterprise suele tener el mejor rendimiento, ya que Redis Enterprise permite que el proceso principal de Redis use varias vCPU. Los niveles basados en código abierto de Redis, como Estándar y Premium, solo pueden usar una vCPU para el proceso de Redis por partición.

  • La prueba comparativa del nivel Enterprise Flash puede ser difícil porque algunas claves se almacenan en DRAM, mientras que algunas se almacenan en un disco flash NVMe. Las claves de la prueba comparativa DRAM son casi tan rápidas como una instancia de nivel Enterprise, pero las claves del disco flash NVMe son más lentas. Dado que el nivel Enterprise Flash coloca de forma inteligente las claves más usadas en DRAM, asegúrese de que la configuración de la prueba comparativa coincida con el uso real que espera. Considere la posibilidad de usar el parámetro -r para elegir de forma aleatoria a qué claves se accede.

  • El uso de TLS/SSL reduce el rendimiento, lo que se puede ver claramente en los datos de pruebas comparativas de ejemplo en las tablas siguientes.

  • Aunque un servidor de Redis es de un solo subproceso, el escalado vertical tiende a mejorar el rendimiento. Los procesos del sistema pueden usar las vCPU adicionales en lugar de compartir la vCPU que usa el proceso de Redis. El escalado vertical es especialmente útil en los niveles Enterprise y Enterprise Flash, ya que Redis Enterprise no está limitado a un único subproceso.

  • En el nivel Premium, suelen recomendarse el escalado horizontal y la agrupación en clústeres antes de escalar verticalmente. La agrupación en clústeres permite que el servidor de Redis use más vCPU mediante el particionamiento de datos. En este caso, el rendimiento debería aumentar de forma aproximadamente lineal al añadir particiones.

  • En las caché EstándarC0 y C1, mientras que el examen interno de Defender se ejecuta en las máquinas virtuales, es posible que veas picos cortos en la carga del servidor que no han causado un aumento en las solicitudes de caché. Verás una mayor latencia para las solicitudes mientras se ejecutan exámenes internos de Defender en estos niveles un par de veces al día. La caché en los niveles C0 y C1 solo tienen un único núcleo a varias tareas, lo que divide el trabajo de atender solicitudes internas de análisis de Defender y Redis. Puedes reducir el efecto escalando a una oferta de nivel superior con varios núcleos de CPU, como C2.

    El aumento del tamaño de la caché en los niveles superiores ayuda a abordar cualquier problema de latencia. Además, en el nivel de C2, tienes compatibilidad con hasta 2000 conexiones de clientes.

Ejemplos de Redis-benchmark

Configuración anterior a la prueba: prepare la instancia de caché con los datos necesarios para las pruebas de latencia y rendimiento:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Para probar la latencia: pruebe las solicitudes GET con una carga de 1 k:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Para probar el rendimiento: solicitudes GET canalizadas con carga de 1 K:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Para probar el rendimiento de una caché de nivel Básico, Estándar o Premium mediante TLS: Solicitudes GET de canalizaciones con carga útil de 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

Para probar el rendimiento de una memoria caché Enterprise o Enterprise Flash sin TLS mediante el modo de clúster del software de código abierto: Solicitudes GET de canalizaciones con carga útil de 1k:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --cluster

Ejemplo de datos de pruebas comparativas de rendimiento

En las tablas siguientes se muestran los valores de rendimiento máximos que se observaron al probar varios tamaños de las memorias caché Estándar, Premium, Enterprise y Enterprise Flash. Usamos redis-benchmark y memtier-benchmark de una máquina virtual de Azure iaaS en el punto de conexión de Azure Cache for Redis. Los números de rendimiento solo son para comandos GET. Normalmente, los comandos SET tienen un rendimiento menor. Estos números están optimizados para el rendimiento. El rendimiento real en condiciones de latencia aceptables podría ser menor.

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 vea resultados mejores o diferentes en la práctica.

Se usó la siguiente configuración para evaluar el rendimiento de los niveles Básico, Estándar y Premium:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Pruebas comparativas de Redis de nivel estándar

Instancia Size vCPU Ancho de banda de red esperado (Mbps) Solicitudes GET por segundo sin SSL (tamaño de valor de 1 kB) Solicitudes GET por segundo sin SSL (tamaño de valor de 1 kB)
C0 250 MB Compartido 100 15,000 7 500
C1 1 GB 1 500 38 000 20 720
C2 2,5 GB 2 500 41 000 37 000
C3 6 GB 4 1000 100 000 90 000
C4 13 GB 2 500 60 000 55 000
C5 26 GB 4 1,000 102 000 93 000
C6 53 GB 8 2\.000 126 000 120 000

Pruebas comparativas de Redis de nivel Premium

Instancia Size vCPU Ancho de banda de red esperado (Mbps) Solicitudes GET por segundo sin SSL (tamaño de valor de 1 kB) Solicitudes GET por segundo sin SSL (tamaño de valor de 1 kB)
P1 6 GB 2 1500 180,000 172 000
P2 13 GB 4 3,000 350 000 341 000
P3 26 GB 4 3,000 350 000 341 000
P4 53 GB 8 6,000 400.000 373 000
P5 120 GB 32 6,000 400.000 373 000

Importante

Las instancias P5 de las regiones Este de China y Norte de China usan 20 núcleos, no 32 núcleos.

Niveles Enterprise y Enterprise Flash

Los niveles Enterprise y Enterprise Flash ofrecen 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.

Se utilizó la siguiente configuración para comparar el rendimiento de los niveles Enterprise y Enterprise Flash:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32

Nota:

Esta configuración es casi idéntica a la utilizada para comparar los niveles Básico, Estándar y Premium. Sin embargo, la configuración anterior no aprovechaba plenamente el mayor rendimiento de proceso de los niveles Enterprise. Se agregaron solicitudes y subprocesos adicionales a esta configuración para demostrar el máximo rendimiento.

Directiva de clúster de Enterprise
Instancia Size vCPU Ancho de banda de red esperado (Mbps) GET solicitudes por segundo sin SSL (tamaño de valor de 1 kB) GET solicitudes por segundo con SSL (tamaño de valor de 1 kB)
E10 12 GB 4 4\.000 300 000 207 000
E20 25 GB 4 4\.000 680,000 480 000
E50 50 GB 8 8,000 1 200 000 900 000
E100 100 GB 16 10 000 1 700 000 1 650 000
F300 384 GB 8 3\.200 500.000 390,000
F700 715 GB 16 6\.400 500.000 370 000
F1500 1455 GB 32 12.800 530,000 390,000
La directiva de clúster de OSS
Instancia Size vCPU Ancho de banda de red esperado (Mbps) GET solicitudes por segundo sin SSL (tamaño de valor de 1 kB) GET solicitudes por segundo con SSL (tamaño de valor de 1 kB)
E10 12 GB 4 4\.000 1 400 000 1 000 000
E20 25 GB 4 4\.000 1 200 000 900 000
E50 50 GB 8 8,000 2 300 000 1 700 000
E100 100 GB 16 10 000 3 000 000 2 500 000
F300 384 GB 8 3\.200 1 500 000 1 200 000
F700 715 GB 16 6\.400 1 600 000 1 200 000
F1500 1455 GB 32 12.800 1 600 000 1 110 000

Niveles Enterprise y Enterprise Flash: escalabilidad horizontal

Además de escalar verticalmente pasando a un tamaño de caché mayor, puede aumentar el rendimiento mediante el escalado horizontal. En los niveles Enterprise, el escalado horizontal se denomina aumento de la capacidad de la instancia de caché. Una instancia de caché tiene de forma predeterminada capacidad para dos, es decir, un nodo principal y de réplica. Una instancia de caché Enterprise con una capacidad de cuatro indica que la instancia se escaló horizontalmente por un factor de dos. El escalado horizontal proporciona acceso a más memoria y vCPU. Puede encontrar detalles sobre cuántas vCPU usa el proceso principal de Redis en cada tamaño de caché y capacidad en la Configuración de particionamiento. El escalado horizontal es más eficaz cuando se usa la directiva de clúster del OSS.

En las tablas siguientes se muestran las solicitudes de GET por segundo en distintas capacidades, mediante SSL y un tamaño de valor de 1 kB.

Escalado horizontal: directiva de clúster Enterprise
Instancia Capacidad 2 Capacidad 4 Capacidad 6
E10 200 000 830 000 930 000
E20 480 000 710,000 950 000
E50 900 000 1 110 000 1 200 000
E100 1 600 000 1 120 000 1 200 000
Instancia Capacidad 3 Capacidad 9
F300 390,000 640 000
F700 370 000 610,000
F1500 390,000 670 000
Escalado horizontal: directiva de clúster del OSS
Instancia Capacidad 2 Capacidad 4 Capacidad 6
E10 1 000 000 1 900 000 2 500 000
E20 900 000 1 700 000 2 300 000
E50 1 700 000 3 000 000 3 900 000
E100 2 500 000 4 400 000 4 900 000
Instancia Capacidad 3 Capacidad 9
F300 1 200 000 2 600 000
F700 1 200 000 2 600 000
F1500 1 100 000 2 800 000

Pasos siguientes