Pruebas de rendimiento

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 cliente que pueda utilizar 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 cachés de nivel Enterprise que usan la directiva de agrupación en clústeres Enterprise 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. Para más información, consulte Procedimientos recomendados del nivel Enterprise.

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

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. Hemos usado redis-benchmark desde una máquina virtual IaaS frente al punto de conexión 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 aceptables de latencia puede ser menor.

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

Nivel Standard

Nivel Premium

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 en Enterprise. 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

Directiva de clúster de Enterprise

La directiva de clúster de OSS

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. En la página Procedimientos recomendados de nivel Enterprise se pueden encontrar detalles sobre el número de vCPU que usa el proceso principal de Redis en cada tamaño y capacidad de caché. 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 GET por segundo en distintas capacidades, mediante SSL y un tamaño de valor de 1 kB.

Escalado horizontal: directiva de clúster Enterprise

Escalado horizontal: directiva de clúster del OSS

Pasos siguientes

• Desarrollo
• Preguntas frecuentes sobre el desarrollo para Azure Cache for Redis
• Conmutación por error y aplicación de revisiones para Azure Cache for Redis