Preguntas frecuentes sobre la administración de caché

En este artículo se proporcionan respuestas a preguntas habituales sobre cómo administrar Azure Cache for Redis.

Importante

Azure Cache for Redis anunció su cronograma de retiro para todos los SKU. Se recomienda mover las instancias existentes de Azure Cache for Redis a Azure Managed Redis tan pronto como pueda.

Para obtener más información sobre la retirada:

• Retirada de Azure Cache for Redis: Qué saber y cómo preparar
• Preguntas más frecuentes sobre la retirada de Azure Cache for Redis

¿Cómo se pueden realizar bancos de pruebas y probar el rendimiento del caché?

• Use redis-benchmark.exe para realizar pruebas de carga en el servidor Redis. Use redis-benchmark.exe para tener una idea del rendimiento posible antes de escribir pruebas de rendimiento propias.
• Useredis-cli para supervisar la caché mediante el comando INFO. Para obtener instrucciones sobre cómo descargar las herramientas de Redis, vea ¿Cómo se pueden ejecutar comandos de Redis?
• Si utiliza Seguridad de la capa de transporte o Capa de sockets seguros (TLS o SSL) en la instancia de caché, agregue el parámetro --tls a los comandos de las herramientas de Redis o utilice un proxy como stunnel para habilitar TLS o SSL.
• Redis-benchmark usa el puerto 6379 de manera predeterminada. Utilice el parámetro -p para invalidar esta configuración si la caché utiliza el puerto 6380 SSL/TLS o el puerto 10000de nivel Enterprise.
• Si es necesario, puede habilitar el puerto que no es TLS desde 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 va a probar. Para obtener los mejores resultados, use máquinas virtuales de la series D y E para los clientes.
• Si usa Windows, habilite el escalado del lado de recepción virtual (VRSS) en el equipo cliente. Para más información, vea 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 la memoria, escale verticalmente a un tamaño de caché mayor.

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

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 prueba SET, 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

¿Cómo se puede habilitar la recolección de elementos no utilizados del servidor para obtener más rendimiento en el cliente al usar StackExchange.Redis?

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

• Elemento <gcServer>
• Fundamentos de la recolección de elementos no utilizados
• Recolección de elementos no utilizados y rendimiento

¿Debo habilitar el puerto que no es TLS/SSL para conectarme a Redis?

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

Nota:

El puerto que no es TLS está deshabilitado de manera predeterminada para las nuevas instancias de Azure Redis. Si el cliente no es compatible con TLS, habilite el puerto que no es TLS siguiendo las instrucciones de Puertos de acceso.

Si la caché usa TLS, debe habilitar TLS mediante la opción --tls 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, vea ¿Cómo se pueden ejecutar comandos de Redis?

¿Cuáles son algunas consideraciones para usar comandos comunes 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 comando KEYS, Redis no procesa los comandos posteriores hasta que termina de procesar el comando KEYS.

  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 claves que se deben usar depende del escenario. Si en el escenario se necesitan claves más grandes, puede ajustar ConnectionTimeout y luego reintentar los valores y ajustar la ló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 instancias de ConnectionMultiplexer, cada una configurada con un conjunto diferente de valores de tiempo de espera y reintento. Para más información, vea ¿Qué hacen las opciones de configuración de StackExchange.Redis?

¿Cuáles son algunas consideraciones de rendimiento para las conexiones?

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 más información sobre los límites de conexión para cada nivel, vea 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.

¿Cuáles son algunas prácticas recomendadas de producción?

• 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 en algunos escenarios se puede producir pérdida de datos. Para más información, vea Solución de problemas de pérdida de datos en Azure Cache for Redis.
• Desarrolle el sistema para que pueda controlar los errores de conexión causados por la aplicación de revisiones 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

• Establezca AbortConnect en false y, después, deje que ConnectionMultiplexer se 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 más información, vea Consideración de 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.

Detalles importantes sobre el crecimiento del grupo de subprocesos

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

• Los subprocesos WORKER se utilizan para tareas como el procesamiento de los métodos Task.Run(…) o ThreadPool.QueueUserWorkItem(…). Varios componentes de CLR también usan estos subprocesos cuando es necesario trabajar en un subproceso en segundo plano.
• Los subprocesos IOCP 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 el valor minimum 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 número de subprocesos minimum, 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 subproceso IOCP, procesa ese trabajo rápidamente. Pero si la ráfaga es mayor que el valor minimum configurado, 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 uno.

Básicamente, cuando el número de subprocesos Busy es mayor de Min subprocesos, se experimenta un retraso de 500 ms antes de que 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 subproceso IOCP, 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.

Nota:

StackExchange.Redis puede alcanzar tiempos de espera si se limita el crecimiento de uno de los subprocesos IOCPo WORKER.

Es mejor establecer el valor de configuración mínimo para los subprocesos IOCP y WORKER 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. Esta configuración también puede afectar el rendimiento de otras partes de aplicaciones complicadas. Debe ajustar esta configuración a las necesidades específicas. Un buen punto de partida es 200 o 300. Después, pruebe y ajuste según sea necesario.

Configuración del valor de subprocesos mínimo

Puede cambiar este valor mediante programación con el método ThreadPool.SetMinThreads (...).

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

    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 a WebApplication.CreateBuilder():

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

Nota:

El valor especificado por este método es un valor global que afecta a la totalidad de AppDomain. Por ejemplo, si tiene una máquina virtual de cuatro núcleos y quiere establecer minWorkerThreads y minIoThreads en 50 por CPU durante el runtime, use ThreadPool.SetMinThreads(200, 200).

También es posible especificar la configuración de subprocesos mínimos mediante minIoThreads o el minWorkerThreadsvalor de configuración en el elemento de configuración <processModel> en Machine.config. Machine.config se encuentra normalmente en %SystemRoot%\Microsoft.NET\Framework\<númeroDeVersión>\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 los subprocesos mínimos de esta manera, debe reiniciar el grupo de aplicaciones.

Nota:

El valor especificado por este método es un valor por núcleo. Por ejemplo, si tiene una máquina de cuatro núcleos y quiere que el valor minIoThreads sea 200 en tiempo de ejecución, use <processModel minIoThreads="50">.

Contenido relacionado

• Vea otras preguntas más frecuentes sobre Azure Cache for Redis.

En este artículo se proporcionan respuestas a preguntas habituales sobre cómo administrar Azure Cache for Redis.

Importante

Azure Cache for Redis anunció su cronograma de retiro para todos los SKU. Se recomienda mover las instancias existentes de Azure Cache for Redis a Azure Managed Redis tan pronto como pueda.

Para obtener más información sobre la retirada:

• Retirada de Azure Cache for Redis: Qué saber y cómo preparar
• Preguntas más frecuentes sobre la retirada de Azure Cache for Redis

• Use redis-benchmark.exe para realizar pruebas de carga en el servidor Redis. Use redis-benchmark.exe para tener una idea del rendimiento posible antes de escribir pruebas de rendimiento propias.
• Useredis-cli para supervisar la caché mediante el comando INFO. Para obtener instrucciones sobre cómo descargar las herramientas de Redis, vea ¿Cómo se pueden ejecutar comandos de Redis?
• Si utiliza Seguridad de la capa de transporte o Capa de sockets seguros (TLS o SSL) en la instancia de caché, agregue el parámetro --tls a los comandos de las herramientas de Redis o utilice un proxy como stunnel para habilitar TLS o SSL.
• Redis-benchmark usa el puerto 6379 de manera predeterminada. Utilice el parámetro -p para invalidar esta configuración si la caché utiliza el puerto 6380 SSL/TLS o el puerto 10000de nivel Enterprise.
• Si es necesario, puede habilitar el puerto que no es TLS desde 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 va a probar. Para obtener los mejores resultados, use máquinas virtuales de la series D y E para los clientes.
• Si usa Windows, habilite el escalado del lado de recepción virtual (VRSS) en el equipo cliente. Para más información, vea 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 la memoria, escale verticalmente a un tamaño de caché mayor.

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

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 prueba SET, 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 cuando se usa StackExchange.Redis. Para más información sobre GC del servidor y cómo habilitarlo, consulte los siguientes artículos.

• Elemento <gcServer>
• Fundamentos de la recolección de elementos no utilizados
• Recolección de elementos no utilizados 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í. Si se conecta a Azure Cache for Redis con un cliente como StackExchange.Redis que admite TLS, use TLS.

Nota:

El puerto que no es TLS está deshabilitado de manera predeterminada para las nuevas instancias de Azure Redis. Si el cliente no es compatible con TLS, habilite el puerto que no es TLS siguiendo las instrucciones de Puertos de acceso.

Si la caché usa TLS, debe habilitar TLS mediante la opción --tls 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, vea ¿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 comando KEYS, Redis no procesa los comandos posteriores hasta que termina de procesar el comando KEYS.

  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 claves que se deben usar depende del escenario. Si en el escenario se necesitan claves más grandes, puede ajustar ConnectionTimeout y luego reintentar los valores y ajustar la ló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 instancias de ConnectionMultiplexer, cada una configurada con un conjunto diferente de valores de tiempo de espera y reintento. Para más información, vea ¿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 más información sobre los límites de conexión para cada nivel, vea 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 en algunos escenarios se puede producir pérdida de datos. Para más información, vea Solución de problemas de pérdida de datos en Azure Cache for Redis.
• Desarrolle el sistema para que pueda controlar los errores de conexión causados por la aplicación de revisiones 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

• Establezca AbortConnect en false y, después, deje que ConnectionMultiplexer se 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 más información, vea Consideración de 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, Trabajo y Puerto de finalización de E/S (IOCP).

• Los subprocesos WORKER se utilizan para tareas como el procesamiento de los métodos Task.Run(…) o ThreadPool.QueueUserWorkItem(…). Varios componentes de CLR también usan estos subprocesos cuando es necesario trabajar en un subproceso en segundo plano.
• Los subprocesos IOCP 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 el valor minimum 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 número de subprocesos minimum, 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 subproceso IOCP, procesa ese trabajo rápidamente. Pero si la ráfaga es mayor que el valor minimum configurado, 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 uno.

Básicamente, cuando el número de subprocesos Busy es mayor de Min subprocesos, se experimenta un retraso de 500 ms antes de que 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 subproceso IOCP, 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.

Nota:

StackExchange.Redis puede alcanzar tiempos de espera si se limita el crecimiento de uno de los subprocesos IOCPo WORKER.

Es mejor establecer el valor de configuración mínimo para los subprocesos IOCP y WORKER 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. Esta configuración también puede afectar el rendimiento de otras partes de aplicaciones complicadas. Debe ajustar esta configuración a las necesidades específicas. Un buen punto de partida es 200 o 300. Después, pruebe y ajuste según sea necesario.

Configuración del valor de subprocesos mínimo

Puede cambiar este valor mediante programación con el método ThreadPool.SetMinThreads (...).

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

    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 a WebApplication.CreateBuilder():

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

Nota:

El valor especificado por este método es un valor global que afecta a la totalidad de AppDomain. Por ejemplo, si tiene una máquina virtual de cuatro núcleos y quiere establecer minWorkerThreads y minIoThreads en 50 por CPU durante el runtime, use ThreadPool.SetMinThreads(200, 200).

También es posible especificar la configuración de subprocesos mínimos mediante minIoThreads o el minWorkerThreadsvalor de configuración en el elemento de configuración <processModel> en Machine.config. Machine.config se encuentra normalmente en %SystemRoot%\Microsoft.NET\Framework\<númeroDeVersión>\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 los subprocesos mínimos de esta manera, debe reiniciar el grupo de aplicaciones.

Nota:

El valor especificado por este método es un valor por núcleo. Por ejemplo, si tiene una máquina de cuatro núcleos y quiere que el valor minIoThreads sea 200 en tiempo de ejecución, use <processModel minIoThreads="50">.

Contenido relacionado

• Vea otras preguntas más frecuentes sobre Azure Cache for Redis.