Preguntas frecuentes sobre la administración de Azure Managed Redis (versión preliminar)

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 ThreadPool para evitar que se agoten los 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 ¿Qué hacen las opciones de configuración de StackExchange.Redis? anterior.

• Habilite los diagnósticos de la memoria caché para que pueda supervisar su estado. 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.

El grupo de subprocesos de CLR tiene dos tipos de subprocesos: subprocesos de "trabajo" y subprocesos de "puertos de terminación de E/S" (lo que se conoce como 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 experimente 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 a continuación.

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, puede 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.

Recomendación

Dada esta información, se recomienda encarecidamente que los clientes establezcan el valor de configuración mínimo para los subprocesos IOPC y de trabajo en un valor algo mayor que el predeterminado. No podemos dar una orientación única sobre cuál debe ser este valor, porque el valor correcto para una aplicación puede ser demasiado alto o bajo para otra. Esta configuración también puede afectar al rendimiento de otras partes de aplicaciones complicadas, por lo que cada cliente debe ajustar este valor de acuerdo con 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 con el método ThreadPool.SetMinThreads (...) de global.asax.cs. Por ejemplo:

  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);
  }
  

  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 desea establecer minWorkerThreads y minIoThreads a 50 por CPU durante el tiempo de ejecución, utilice ThreadPool.SetMinThreads(200, 200).

• También es posible especificar el ajuste mínimo de hilos mediante el ajuste de configuración minIoThreads o minWorkerThreads en el elemento de configuración <processModel> en 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 forma, ya que es una configuración que afecta a todo el sistema.

  Nota

  El valor especificado en este elemento de configuración es por núcleo. Por ejemplo, si tiene una máquina con cuatro núcleos y desea que la configuración de minIoThreads sea 200 en tiempo de ejecución, utilice <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 elementos no utilizados
• 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. Si bien cada tamaño de caché permite hasta cierta cantidad de conexiones, cada conexión a Redis tiene asociada una sobrecarga. 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. Para más información sobre las conexiones y otras configuraciones predeterminadas, consulte Configuración predeterminada del servidor Redis.

Pasos siguientes

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