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
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.
El cliente para pruebas de máquina virtual debe estar en la misma región que la instancia de Azure Cache for Redis.
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.
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.
Si usa TLS/SSL en la instancia de caché, debe agregar el
--tlsparámetro al comando redis-benchmark o usar un proxy como stunnel.Redis-benchmarkusa el puerto 6379, de manera predeterminada. Use el parámetro-ppara invalidar esta configuración. Debe usar-p, si usa SSL/TLS (puerto 6380) o usa el nivel Enterprise (puerto 10000).Si usa una instancia de Azure Cache for Redis que usa la agrupación en clústeres, debe agregar el parámetro
--clusteral comandoredis-benchmark. Las cachés de nivel Enterprise que usan la agrupación en clústeres Enterprise se pueden tratar como cachés no agrupadas y no necesitan esta configuración.Inicie
redis-benchmarkdesde 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
-rpara 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 |