Administración de la carga del servidor en Azure Cache for Redis
Tamaños de valor
El diseño de la aplicación cliente determina si debe almacenar muchos valores pequeños o un número menor de valores mayores. Desde la perspectiva del servidor Redis, los valores menores ofrecen un mejor rendimiento. Se recomienda mantener un tamaño de valor inferior a 100 kB.
Si el diseño requiere que almacene valores mayores en Azure Cache for Redis, la carga del servidor será mayor. En este caso, es posible que tenga que usar un nivel de caché superior para asegurarse de que el uso de CPU no limita el rendimiento.
Incluso si la caché tiene suficiente capacidad de CPU, los valores más grandes aumentan las latencias, por lo que debe seguir las instrucciones que se indican en Configuración de tiempos de espera adecuados.
Los valores más grandes también aumentan las posibilidades de fragmentación de memoria, por lo que debe seguir las instrucciones que se indican en Configuración de la opción maxmemory-reserved.
Evitar picos de conexión cliente
La creación y el cierre de las conexiones es una operación costosa para el servidor Redis. Si la aplicación cliente crea o cierra demasiadas conexiones en un período de tiempo pequeño, podría sobrecargar el servidor Redis.
Si va a crear instancias de muchas instancias de cliente para que se conecten a Redis a la vez, considere la posibilidad de escalonar las nuevas creaciones de conexión para evitar un pico excesivo en el número de clientes conectados.
Presión de memoria
El uso elevado de memoria en el servidor hace que sea más probable que el sistema tenga que paginar los datos en el disco, lo que da lugar a errores de página que pueden ralentizar significativamente el sistema.
Evitar comandos de larga duración
El servidor Redis es un sistema de un solo subproceso. Los comandos de larga duración pueden provocar latencia o tiempos de espera en el lado cliente porque el servidor no puede responder a otras solicitudes mientras está ocupado trabajando en un comando de larga duración. Para más información, consulte Solución de problemas del lado servidor de Azure Cache for Redis.
Supervisión de la carga del servidor
Agregue supervisión en la carga del servidor para asegurarse de que recibe notificaciones cuando se produzca una carga elevada del servidor. La supervisión puede ayudarle a comprender las restricciones de la aplicación. Luego, puede trabajar de forma proactiva para mitigar los problemas. Se recomienda intentar mantener la carga del servidor por debajo del 80 % para evitar efectos negativos en el rendimiento. Una carga sostenida del servidor superior al 80 % puede provocar conmutaciones por error no planeadas. Actualmente, Azure Cache For Redis expone dos métricas en Insights en Supervisión en el menú de recursos de la izquierda del portal: CPU y Carga del servidor. Es importante saber lo que mide cada métrica al supervisar la carga del servidor.
La métrica CPU indica el uso de CPU en el nodo que hospeda la caché. La métrica CPU también incluye procesos que no son estrictamente procesos del servidor Redis. La CPU incluye procesos en segundo plano para antimalware y otros. En consecuencia, la métrica CPU a veces puede presentar picos y podría no ser un indicador perfecto del uso de la CPU para el servidor Redis.
La métrica Carga del servidor representa la carga solo en el servidor Redis. Se recomienda supervisar la métrica Carga del servidor, en lugar de CPU.
Al supervisar la carga del servidor, también se recomienda examinar los picos máximos de carga del servidor en lugar del promedio, ya que incluso los breves picos pueden desencadenar conmutaciones por error y tiempos de espera de comandos.
Planeamiento del mantenimiento del servidor
Asegúrese de que tiene capacidad suficiente en el servidor para controlar la carga máxima mientras los servidores de caché se someten a mantenimiento. Para probar el sistema, reinicie los nodos mientras está bajo carga máxima. Para más información sobre cómo simular la implementación de una revisión, consulte Reinicio.
Prueba del aumento de la carga del servidor después de la conmutación por error
En el caso de las SKU estándar y prémium, cada caché está hospedada en dos nodos. Un equilibrador de carga distribuye las conexiones de cliente a los dos nodos. Cuando se produce un mantenimiento planeado o no planeado en el nodo principal, este cierra todas las conexiones de cliente. En este caso, todas las conexiones de cliente podrían distribuirse a un solo nodo, lo que provocaría que la carga del servidor aumentara en el nodo restante. Para probar este escenario, se recomienda reiniciar el nodo principal y asegurarse de que un nodo puede controlar todas las conexiones de cliente sin que la carga del servidor sea demasiado alta.