Preguntas más frecuentes sobre la administración de Azure Managed Redis

Este artículo proporciona respuestas a preguntas comunes sobre cómo administrar Azure Managed Redis.

¿Cuándo se debe habilitar el puerto que no es TLS/SSL para la conexión a Redis?

El uso de TLS se recomienda como mejor práctica en prácticamente todos los casos de uso de Redis. La opción de conectarse sin TLS se incluye por motivos de compatibilidad con versiones anteriores.

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

• Prácticas recomendadas de StackExchange.Redis
• Configuración y conceptos
• Pruebas de rendimiento

Prácticas recomendadas de StackExchange.Redis

• Establecer AbortConnect en false y deje que el 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. En la discusión de Redis, 100 kb se considera grande. Para obtener más información, consulte los Desarrollo de procedimientos recomendados.
• Configure los valores de ThreadPool para evitar tiempos de espera.
• Utilice al menos el valor de connectTimeout predeterminado de 5 segundos. Este intervalo da el tiempo suficiente a StackExchange.Redis para volver a establecer la conexión en caso de una interrupción momentánea de la red.
• Tenga en cuenta los costos de rendimiento de las diferentes operaciones que se estén ejecutando. Por ejemplo, el comando KEYS es una operación O(n) y debe evitarse. El sitio redis.io tiene información sobre la complejidad de tiempo de cada operación admitida. Seleccione cada comando para ver la complejidad de cada operación.

Configuración y conceptos

• Recuerde que Redis es un almacén de datos en memoria . Para obtener más información, consulte Solución de problemas de pérdida de datos en Azure Managed Redis para conocer las situaciones en las que se puede producir una pérdida de datos.
• Desarrolle el sistema para que pueda controlar interrupciones momentáneas de conexión provocadas por la aplicación de revisiones y la conmutación por error.

Pruebas de rendimiento

• Consulte Pruebas de rendimiento con Azure Managed Redis para ver ejemplos de puntos de referencia e instrucciones para ejecutar sus propias pruebas de rendimiento en Azure Managed Redis.

¿Cuáles son algunas de las consideraciones al usar los comandos de Redis comunes?

• 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. Cada fragmento de Redis es un único hilo y procesa los comandos de uno en uno. Si ha emitido otros comandos después de KEYS, no se procesarán hasta que Redis procese el comando KEYS. El sitio redis.io tiene información sobre la complejidad de tiempo de cada operación admitida. Seleccione cada comando para ver la complejidad de cada operación.
• Tamaños de clave: ¿debo usar claves/valores pequeños o claves/valores grandes? Depende del escenario. Si su escenario requiere claves de mayor tamaño, puede ajustar el valor de ConnectionTimeout y los valores de reintento y ajustar la lógica de reintento. Desde la perspectiva del servidor Redis, los valores menores ofrecen un mejor rendimiento.
• Estas consideraciones no significan que no pueda almacenar valores mayores en Redis, simplemente debe tenerlas en cuenta. Las latencias son mayores. Si tiene un conjunto de datos de mayor tamaño y otro de menor tamaño, puede usar varias instancias de ConnectionMultiplexer. Configure cada una con un conjunto diferente de valores de tiempo de espera y reintento, como se describe en la sección Anterior What do the StackExchange.Redis configuration options do (Qué hacen las opciones de configuración de StackExchange.Redis ).

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

• Habilite los diagnósticos de caché para que pueda supervisar el estado de la caché. Puede ver las métricas en Azure Portal y también descargarlas y revisarlas mediante las herramientas que prefiera.
• Consulte Pruebas de rendimiento con Azure Managed Redis para ver ejemplos de puntos de referencia e instrucciones para ejecutar sus propias pruebas de rendimiento en Azure Managed Redis.

Detalles importantes sobre el crecimiento del grupo de subprocesos

ClR ThreadPool tiene dos tipos de subprocesos: subprocesos de puerto de finalización de E / S y de trabajo (IOCP).

• Los subprocesos de trabajo se utilizan para aspectos como el procesamiento de los métodos Task.Run(…) o ThreadPool.QueueUserWorkItem(…). Estos subprocesos también se utilizan en varios componentes del CLR cuando el trabajo se debe ejecutar en un subproceso en segundo plano.
• Los subprocesos IOCP se usan cuando se produce E/S asincrónica (por ejemplo, cuando se lee de la red).

El grupo de subprocesos proporciona nuevos subprocesos de trabajo o de terminación de E/S a petición (sin limitación) hasta que se llega a la configuración "mínima" de 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 existentes (ocupados) alcanza el número "mínimo" de subprocesos, ThreadPool regula la velocidad a la que inyecta nuevos subprocesos a un subproceso cada 500 milisegundos. Normalmente, si el sistema recibe una ráfaga de trabajo que necesita un hilo IOCP, lo procesa rápidamente. Sin embargo, si la ráfaga es mayor que la configuración "mínima" establecida, habrá cierto retraso en el procesamiento de parte del trabajo, ya que el grupo de subprocesos 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 subprocesos ocupados es mayor que los subprocesos mínimos, es probable que pague un retraso de 500 ms antes de que la aplicación procese el tráfico de red. Además, cuando un hilo existente permanece inactivo durante más de 15 segundos, se limpia y este ciclo de crecimiento y contracción puede repetirse.

Si examinamos un mensaje de error de ejemplo de StackExchange.Redis (compilación 1.0.450 o posterior), verá que ahora se imprimen las estadísticas del grupo de subprocesos. Consulte los detalles de IOCP y WORKER más adelante en el artículo.

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)

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

Nota:

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

Recomendación

Se recomienda que los clientes establezcan el valor de configuración mínimo para los subprocesos IOCP y WORKER en algo mayor que el valor predeterminado. No podemos proporcionar instrucciones de un solo tamaño en este valor porque el valor adecuado para una aplicación puede ser demasiado alto o bajo para otra aplicación. Esta configuración también puede afectar el rendimiento de otras partes de aplicaciones complicadas. Cada cliente debe ajustar esta configuración a sus necesidades específicas. Un buen punto de partida es 200 o 300, y luego probar y ajustar según sea necesario.

Cómo configurar este valor:

Se recomienda cambiar esta configuración mediante programación mediante el método ThreadPool.SetMinThreads (...) en aplicaciones de .NET Framework y .NET Core.

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

```csharp
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, establézcalo en Program.cs, justo antes de la llamada a WebApplication.CreateBuilder():

```csharp
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 una configuración global, que afecta a todo AppDomain. Por ejemplo, si tiene una máquina con cuatro núcleos y quiere establecer minWorkerThreads y minIoThreads en 50 por CPU durante el tiempo de ejecución, use ThreadPool.SetMinThreads(200, 200).

También es posible especificar la configuración de subprocesos mínimos mediante la minIoThreadsminWorkerThreads o en el <processModel> elemento de configuración de Machine.config. Machine.config normalmente se encuentra 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 lo establece de esta manera, debe reiniciar el grupo de aplicaciones.

Nota:

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

Habilitación de GC del servidor para obtener más rendimiento en el cliente cuando se usa StackExchange.Redis

La habilitación de GC del servidor puede optimizar el cliente y mejorar el rendimiento y la capacidad cuando se usa StackExchange.Redis. Para más información sobre GC del servidor y cómo habilitarlo, consulte los siguientes artículos.

• Para habilitar GC del servidor
• Fundamentos de la recolección de basura
• Recolección de elementos no utilizados y rendimiento

Consideraciones sobre rendimiento de las conexiones

Las distintas SKU pueden tener límites diferentes en cuanto a conexiones de clientes, memoria y ancho de banda. Aunque cada tamaño de caché permite hasta cierto número de conexiones, cada conexión a Redis tiene una sobrecarga asociada. Un ejemplo de dicha sobrecarga podría ser el uso de memoria y CPU 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 excede la capacidad del sistema, la caché puede experimentar problemas de capacidad incluso si no se excede el límite de conexión para el tamaño de caché actual.

Para obtener más información sobre los distintos límites de conexiones para cada nivel, consulte Precios de Azure Managed Redis.

Contenido relacionado

• Obtenga más información sobre otras Preguntas frecuentes sobre Azure Managed Redis.

Este artículo proporciona respuestas a preguntas comunes sobre cómo administrar Azure Managed Redis.

El uso de TLS se recomienda como mejor práctica en prácticamente todos los casos de uso de Redis. La opción de conectarse sin TLS se incluye por motivos de compatibilidad con versiones anteriores.

• Prácticas recomendadas de StackExchange.Redis
• Configuración y conceptos
• Pruebas de rendimiento

Prácticas recomendadas de StackExchange.Redis

• Establecer AbortConnect en false y deje que el 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. En la discusión de Redis, 100 kb se considera grande. Para obtener más información, consulte los Desarrollo de procedimientos recomendados.
• Configure los valores de ThreadPool para evitar tiempos de espera.
• Utilice al menos el valor de connectTimeout predeterminado de 5 segundos. Este intervalo da el tiempo suficiente a StackExchange.Redis para volver a establecer la conexión en caso de una interrupción momentánea de la red.
• Tenga en cuenta los costos de rendimiento de las diferentes operaciones que se estén ejecutando. Por ejemplo, el comando KEYS es una operación O(n) y debe evitarse. El sitio redis.io tiene información sobre la complejidad de tiempo de cada operación admitida. Seleccione cada comando para ver la complejidad de cada operación.

Configuración y conceptos

• Recuerde que Redis es un almacén de datos en memoria . Para obtener más información, consulte Solución de problemas de pérdida de datos en Azure Managed Redis para conocer las situaciones en las que se puede producir una pérdida de datos.
• Desarrolle el sistema para que pueda controlar interrupciones momentáneas de conexión provocadas por la aplicación de revisiones y la conmutación por error.

Pruebas de rendimiento

• Consulte Pruebas de rendimiento con Azure Managed Redis para ver ejemplos de puntos de referencia e instrucciones para ejecutar sus propias pruebas de rendimiento en Azure Managed 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. Cada fragmento de Redis es un único hilo y procesa los comandos de uno en uno. Si ha emitido otros comandos después de KEYS, no se procesarán hasta que Redis procese el comando KEYS. El sitio redis.io tiene información sobre la complejidad de tiempo de cada operación admitida. Seleccione cada comando para ver la complejidad de cada operación.
• Tamaños de clave: ¿debo usar claves/valores pequeños o claves/valores grandes? Depende del escenario. Si su escenario requiere claves de mayor tamaño, puede ajustar el valor de ConnectionTimeout y los valores de reintento y ajustar la lógica de reintento. Desde la perspectiva del servidor Redis, los valores menores ofrecen un mejor rendimiento.
• Estas consideraciones no significan que no pueda almacenar valores mayores en Redis, simplemente debe tenerlas en cuenta. Las latencias son mayores. Si tiene un conjunto de datos de mayor tamaño y otro de menor tamaño, puede usar varias instancias de ConnectionMultiplexer. Configure cada una con un conjunto diferente de valores de tiempo de espera y reintento, como se describe en la sección Anterior What do the StackExchange.Redis configuration options do (Qué hacen las opciones de configuración de StackExchange.Redis ).

• Habilite los diagnósticos de caché para que pueda supervisar el estado de la caché. Puede ver las métricas en Azure Portal y también descargarlas y revisarlas mediante las herramientas que prefiera.
• Consulte Pruebas de rendimiento con Azure Managed Redis para ver ejemplos de puntos de referencia e instrucciones para ejecutar sus propias pruebas de rendimiento en Azure Managed Redis.

ClR ThreadPool tiene dos tipos de subprocesos: subprocesos de puerto de finalización de E / S y de trabajo (IOCP).

• Los subprocesos de trabajo se utilizan para aspectos como el procesamiento de los métodos Task.Run(…) o ThreadPool.QueueUserWorkItem(…). Estos subprocesos también se utilizan en varios componentes del CLR cuando el trabajo se debe ejecutar en un subproceso en segundo plano.
• Los subprocesos IOCP se usan cuando se produce E/S asincrónica (por ejemplo, cuando se lee de la red).

El grupo de subprocesos proporciona nuevos subprocesos de trabajo o de terminación de E/S a petición (sin limitación) hasta que se llega a la configuración "mínima" de 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 existentes (ocupados) alcanza el número "mínimo" de subprocesos, ThreadPool regula la velocidad a la que inyecta nuevos subprocesos a un subproceso cada 500 milisegundos. Normalmente, si el sistema recibe una ráfaga de trabajo que necesita un hilo IOCP, lo procesa rápidamente. Sin embargo, si la ráfaga es mayor que la configuración "mínima" establecida, habrá cierto retraso en el procesamiento de parte del trabajo, ya que el grupo de subprocesos 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 subprocesos ocupados es mayor que los subprocesos mínimos, es probable que pague un retraso de 500 ms antes de que la aplicación procese el tráfico de red. Además, cuando un hilo existente permanece inactivo durante más de 15 segundos, se limpia y este ciclo de crecimiento y contracción puede repetirse.

Si examinamos un mensaje de error de ejemplo de StackExchange.Redis (compilación 1.0.450 o posterior), verá que ahora se imprimen las estadísticas del grupo de subprocesos. Consulte los detalles de IOCP y WORKER más adelante en el artículo.

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)

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

Nota:

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

Recomendación

Se recomienda que los clientes establezcan el valor de configuración mínimo para los subprocesos IOCP y WORKER en algo mayor que el valor predeterminado. No podemos proporcionar instrucciones de un solo tamaño en este valor porque el valor adecuado para una aplicación puede ser demasiado alto o bajo para otra aplicación. Esta configuración también puede afectar el rendimiento de otras partes de aplicaciones complicadas. Cada cliente debe ajustar esta configuración a sus necesidades específicas. Un buen punto de partida es 200 o 300, y luego probar y ajustar según sea necesario.

Cómo configurar este valor:

Se recomienda cambiar esta configuración mediante programación mediante el método ThreadPool.SetMinThreads (...) en aplicaciones de .NET Framework y .NET Core.

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

```csharp
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, establézcalo en Program.cs, justo antes de la llamada a WebApplication.CreateBuilder():

```csharp
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 una configuración global, que afecta a todo AppDomain. Por ejemplo, si tiene una máquina con cuatro núcleos y quiere establecer minWorkerThreads y minIoThreads en 50 por CPU durante el tiempo de ejecución, use ThreadPool.SetMinThreads(200, 200).

También es posible especificar la configuración de subprocesos mínimos mediante la minIoThreadsminWorkerThreads o en el <processModel> elemento de configuración de Machine.config. Machine.config normalmente se encuentra 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 lo establece de esta manera, debe reiniciar el grupo de aplicaciones.

Nota:

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

La habilitación de GC del servidor puede optimizar el cliente y mejorar el rendimiento y la capacidad cuando se usa StackExchange.Redis. Para más información sobre GC del servidor y cómo habilitarlo, consulte los siguientes artículos.

• Para habilitar GC del servidor
• Fundamentos de la recolección de basura
• Recolección de elementos no utilizados y rendimiento

Las distintas SKU pueden tener límites diferentes en cuanto a conexiones de clientes, memoria y ancho de banda. Aunque cada tamaño de caché permite hasta cierto número de conexiones, cada conexión a Redis tiene una sobrecarga asociada. Un ejemplo de dicha sobrecarga podría ser el uso de memoria y CPU 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 excede la capacidad del sistema, la caché puede experimentar problemas de capacidad incluso si no se excede el límite de conexión para el tamaño de caché actual.

Para obtener más información sobre los distintos límites de conexiones para cada nivel, consulte Precios de Azure Managed Redis.

Contenido relacionado

• Obtenga más información sobre otras Preguntas frecuentes sobre Azure Managed Redis.