Preguntas frecuentes sobre la administración de caché

• Utilícelo redis-benchmark.exe para realizar pruebas de carga en el servidor Redis. Utilícelo redis-benchmark.exe para tener una idea del rendimiento posible antes de escribir sus propias pruebas de rendimiento.
• Utilícelo redis-cli para supervisar la caché mediante el INFO comando. Para obtener instrucciones sobre cómo descargar las herramientas de Redis, consulte ¿Cómo se pueden ejecutar comandos de Redis?
• Si utiliza Transport Layer Security/Secure Socket Layer (TLS/SSL) en la instancia de caché, agregue el parámetro a los comandos de --tls las herramientas de Redis o utilice un proxy como stunnel para habilitar TLS/SSL.
• Redis-benchmark Utiliza el puerto 6379 de forma predeterminada. Utilice el -p parámetro para invalidar esta configuración si la memoria caché utiliza el puerto 6380 SSL/TLS o el puerto 10000de nivel Enterprise .
• Si es necesario, puede habilitar el puerto que no es TLS a través de Azure Portal antes de ejecutar la prueba de carga.
• Asegúrese de que la máquina virtual (VM) cliente que usa para las pruebas está en la misma región que la instancia de Azure Cache for Redis.
• Asegúrese de que la máquina virtual cliente tenga al menos tanta capacidad informática y de ancho de banda como la caché que está probando. Para obtener los mejores resultados, use máquinas virtuales de la serie D y la serie E para los clientes.
• Si está en Windows, habilite el escalado del lado de recepción virtual (VRSS) en el equipo cliente. Para obtener más información, consulte Escalado virtual del lado de recepción en Windows Server 2012 R2.
• Habilite los diagnósticos de caché para que pueda supervisar el estado de la caché. Puede ver las métricas en Azure Portal, así como descargar y revisar las métricas con las herramientas que prefiera.
• Si la carga provoca una gran fragmentación de memoria, escale verticalmente a un tamaño de caché mayor.

En los ejemplos siguientes se muestra cómo utilizar redis-benchmark.exe. Ejecute estos comandos desde una máquina virtual en la misma región que la caché para obtener resultados precisos.

En primer lugar, pruebe las solicitudes canalizadas SET con una carga útil de 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

Después de ejecutar la SET prueba, ejecute solicitudes canalizadas GET mediante una carga útil de 1k:

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

La habilitación de la recolección de elementos no utilizados del servidor (GC) puede optimizar el cliente y proporcionar un mejor rendimiento y rendimiento cuando se usa StackExchange.Redis. Para más información sobre GC del servidor y cómo habilitarlo, consulte los siguientes artículos.

• El <elemento gcServer>
• Fundamentos de la recolección de basura
• Recolección de basura y rendimiento

El servidor de Redis no admite de forma nativa la seguridad de la capa de transporte (TLS), pero Azure Cache for Redis sí admite TLS. Si se conecta a Azure Cache for Redis con un cliente como StackExchange.Redis que admite TLS, use TLS.

Si la caché usa TLS, debe habilitar TLS mediante la --tls opción para herramientas de Redis como redis-cli. También puede usar una utilidad como stunnel para conectar de forma segura las herramientas al puerto TLS siguiendo las instrucciones de la entrada de blog Anuncio del proveedor de estado de sesión ASP.NET para la versión preliminar de Redis .

Para obtener instrucciones sobre cómo descargar las herramientas de Redis, consulte ¿Cómo se pueden ejecutar comandos de Redis?

• Evite usar determinados comandos de Redis que tardan mucho tiempo en completarse a menos que conozca completamente el resultado de estos comandos. Por ejemplo, no ejecute el comando KEYS en producción. Dependiendo del número de claves, puede tardar mucho tiempo en completarse. Redis es un servidor de un solo subproceso que procesa los comandos de uno en uno. Si emite el KEYS comando, Redis no procesa los comandos posteriores hasta que termina de procesar el KEYS comando.

  El sitio redis.io tiene detalles de complejidad de tiempo para cada operación que admite. Seleccione cada comando para ver la complejidad de cada operación.

• El tamaño de las teclas que se deben usar depende del escenario. Si el escenario requiere claves más grandes, puede ajustar los valores de , luego reintentar y ajustar la ConnectionTimeoutlógica de reintento. Desde el punto de vista del servidor Redis, los valores de clave más pequeños proporcionan un mejor rendimiento.

• Estas consideraciones no significan que no pueda almacenar valores más grandes en Redis, pero las latencias son más altas. Si tiene un conjunto de datos mayor que otro, puede usar varias ConnectionMultiplexer instancias, cada una configurada con un conjunto diferente de valores de tiempo de espera y reintento. Para obtener más información, consulte ¿Qué hacen las opciones de configuración de StackExchange.Redis?

Cada plan de tarifa de Azure Cache for Redis tiene límites diferentes para las conexiones de cliente, la memoria y el ancho de banda. Aunque cada tamaño de caché permite hasta un cierto número de conexiones, cada conexión a Redis implica una sobrecarga asociada. Un ejemplo de esta sobrecarga es el uso de la CPU y la memoria debido al cifrado TLS/SSL.

El límite máximo de conexiones para un tamaño de caché determinado supone una caché con poca carga. Si la carga de la sobrecarga de conexión más la carga de las operaciones del cliente supera la capacidad del sistema, la memoria caché puede experimentar problemas de capacidad incluso si no supera el límite de conexión para el tamaño de caché actual.

Para obtener más información sobre los límites de conexión para cada nivel, consulte Precios de Azure Cache for Redis. Para más información sobre las conexiones y otras configuraciones predeterminadas, consulte Configuración predeterminada del servidor Redis.

• Utilice el nivel Estándar o Premium para los sistemas de producción. El nivel básico es un sistema de nodo único sin replicación de datos ni acuerdo de nivel de servicio (SLA). Además, utilice al menos una caché C1 para producción. Las cachés C0 se usan normalmente en escenarios de desarrollo o pruebas sencillos.
• Tenga en cuenta que Redis es un almacén de datos en memoria y que la pérdida de datos puede producirse en algunos escenarios. Para más información, consulte Solución de problemas de pérdida de datos en Azure Cache for Redis.
• Desarrolle su sistema para que pueda manejar los errores de conexión causados por la aplicación de parches y la conmutación por error.
• Use instancias de Azure Redis de nivel Premium para mejorar la latencia y el rendimiento de la red, ya que tienen mejor hardware tanto para la CPU como para la red.

Prácticas recomendadas de StackExchange.Redis

• Establézcalo AbortConnect en falso y, a continuación, deje que se ConnectionMultiplexer vuelva a conectar automáticamente.
• Use una única instancia de larga duración ConnectionMultiplexer en lugar de crear una nueva conexión para cada solicitud.
• Redis funciona mejor con valores más pequeños, por lo que puede cortar los datos más grandes en varias claves. Por ejemplo, en ¿Cuál es el rango de tamaño de valor ideal para redis?, 100 kb se considera grande. Para obtener más información, consulte Considerar más claves y valores más pequeños.
• Configure ThreadPool para evitar que se agoten los tiempos de espera.
• Utilice al menos el valor predeterminado connectTimeout de 5 segundos. Este intervalo le da a StackExchange.Redis tiempo suficiente para restablecer la conexión si hay un problema de red.
• Tenga en cuenta los costos de rendimiento asociados a las diferentes operaciones que ejecute. Por ejemplo, el comando KEYS es una operación O(n) y debe evitarse. El sitio redis.io tiene detalles sobre la complejidad temporal de cada operación que admite. Seleccione cada comando para ver la complejidad de cada operación.

El grupo de subprocesos de Common Language Runtime (CLR) tiene dos tipos de subprocesos, Worker y Puerto de finalización de E/S (IOCP).

• WORKER Los subprocesos se utilizan para cosas como el procesamiento de los Task.Run(…)métodos , o ThreadPool.QueueUserWorkItem(…) . Varios componentes de CLR también usan estos subprocesos cuando es necesario trabajar en un subproceso en segundo plano.
• IOCP Los subprocesos se utilizan para E/S asincrónica, como cuando se lee desde la red.

El grupo de subprocesos proporciona nuevos subprocesos de trabajo o subprocesos de finalización de E/S a petición sin ninguna limitación hasta que alcanza la minimum configuración para cada tipo de subproceso. De forma predeterminada, el número mínimo de subprocesos se establece en el número de procesadores en un sistema.

Una vez que el número de subprocesos ocupados existentes alcanza el minimum número de subprocesos, ThreadPool limita la velocidad a la que inserta nuevos subprocesos en un subproceso cada 500 milisegundos.

Normalmente, si el sistema recibe una ráfaga de trabajo que necesita un IOCP subproceso, procesa ese trabajo rápidamente. Sin embargo, si la ráfaga es mayor que la configuración configurada minimum , hay algún retraso en el procesamiento de parte del trabajo, ya que ThreadPool espera una de estas dos posibilidades:

• Un subproceso existente queda libre para procesar el trabajo.
• Ningún subproceso existente queda libre durante 500 ms, por lo que se crea un nuevo subproceso.

Básicamente, cuando el número de Busy subprocesos es mayor que el de subprocesos, se experimenta un retraso de 500 ms antes de que Min la aplicación procese el tráfico de red. Además, se limpia un subproceso existente que permanece inactivo durante más de 15 segundos y este ciclo de crecimiento y contracción puede repetirse.

Los mensajes de error de StackExchange.Redis compilación 1.0.450 o posterior imprimen estadísticas de ThreadPool, como se muestra en el ejemplo siguiente.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

En el ejemplo se muestra que para el IOCP subproceso, hay seis subprocesos ocupados y el sistema está configurado para permitir cuatro subprocesos mínimos. En este caso, es probable que el cliente vea dos retrasos de 500 ms, porque 6 > 4.

Es mejor establecer el valor IOCP de configuración mínimo para y WORKER los subprocesos en algo mayor que el valor predeterminado. No existe una guía única para este valor, ya que es probable que el valor correcto para una aplicación sea demasiado alto o bajo para otra aplicación. Esta configuración también puede afectar el rendimiento de otras partes de aplicaciones complicadas. Debe ajustar esta configuración a sus necesidades específicas. Un buen punto de partida es 200 o 300. A continuación, pruebe y ajuste según sea necesario.

Configurar la configuración de subprocesos mínimos

Puede cambiar esta configuración mediante programación mediante el método ThreadPool.SetMinThreads (... ).

Por ejemplo, en NET Framework, se establece este valor en Global.asax.cs en el Application_Start método:

    private readonly int minThreads = 200;
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        ThreadPool.SetMinThreads(minThreads, minThreads);
    }

Si usa .NET Core, establezca el valor en Program.cs justo antes de la llamada en WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

También es posible especificar la configuración de subprocesos mínimos mediante la minIoThreadsminWorkerThreads o en el <processModel> elemento de configuración en Machine.config. Machine.config se encuentra normalmente en %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

No se recomienda establecer el número mínimo de subprocesos de esta manera, ya que se trata de una configuración de todo el sistema. Si establece subprocesos mínimos de esta manera, debe reiniciar el grupo de aplicaciones.

Contenido relacionado

• Consulte otras preguntas más frecuentes de Azure Cache for Redis.