Modifier

Partager via

FAQ sur la gestion d’Azure Managed Redis (en préversion)

  • Forum aux questions

Cet article fournit des réponses aux questions fréquentes sur la gestion d’Azure Managed Redis.

Quand dois-je activer le port non TLS/SSL pour la connexion à Redis ?

L'utilisation de TLS est recommandée comme meilleure pratique dans pratiquement tous les cas d'utilisation de Redis. L’option de connexion sans TLS est incluse à des fins de compatibilité descendante.

Remarque

Le port non TLS est désactivé par défaut pour les nouvelles instances Azure Managed Redis (en préversion). Si votre client ne prend pas en charge TLS, vous devez activer le port non TLS en suivant les instructions de la section Ports d’accès de l’article Configuration d’un cache dans Azure Managed Redis.

Quelles sont les meilleures pratiques en matière de production ?

Meilleures pratiques StackExchange.Redis

  • Définissez AbortConnect sur false, puis laissez le ConnectionMultiplexer se reconnecter automatiquement.
  • Utilisez une seule instance ConnectionMultiplexer de longue durée plutôt que de créer une connexion pour chaque requête.
  • Redis fonctionne de manière optimale avec des valeurs plus petites et il est donc recommandé de fractionner les données plus volumineuses dans plusieurs clés. Dans cette discussion sur Redis, la valeur 100 Ko est considérée comme un grand volume. Pour plus d’informations, consultez les bonnes pratiques de développement.
  • Configurez vos paramètres ThreadPool pour éviter les délais d’attente.
  • Utilisez au moins la valeur par défaut connectTimeout de 5 secondes. Cet intervalle laisse à StackExchange.Redis suffisamment de temps pour rétablir la connexion en cas de blocage du réseau.
  • Faites attention aux coûts de performances associés aux différentes opérations que vous exécutez. Par exemple, la commande KEYS est une opération O(n) et doit être évitée. Le site redis.io fournit plus d’informations sur la complexité de temps de chaque opération prise en charge. Sélectionnez chaque commande pour voir la complexité de chaque opération.

Configuration et concepts

Tests de performances

Quels sont les points à prendre en compte en ce qui concerne les commandes Redis les plus courantes ?

  • Évitez d’utiliser certaines commandes Redis qui durent longtemps, sauf si vous comprenez pleinement leur résultat. Par exemple, n’exécutez pas la commande KEYS en production. Selon le nombre de clés, la commande peut prendre beaucoup de temps pour s’exécuter. Chaque étendue de Redis est un thread unique et traite une commande à la fois. Si vous avez émis d’autres commandes après KEYS, elles ne sont pas traitées tant que Redis traite la commande KEYS. Le site redis.io fournit plus d’informations sur la complexité de temps de chaque opération prise en charge. Sélectionnez chaque commande pour voir la complexité de chaque opération.
  • Taille des clés : dois-je utiliser des petites clés/valeurs ou de grandes clés/valeurs ? Cela dépend du scénario. Si votre scénario nécessite des clés plus longues, vous pouvez ajuster les valeurs ConnectionTimeout, puis les réessayer avant d’adapter votre logique de nouvelle tentative. Du point de vue du serveur Redis, les valeurs les plus petites donnent de meilleures performances.
  • Cela ne veut pas dire que vous ne pouvez pas stocker de plus grandes valeurs dans Redis. Vous devez simplement être au fait de ces informations. Les latences sont plus élevées. Si vous avez un jeu de données plus grand et un autre plus petit, vous pouvez utiliser plusieurs instances ConnectionMultiplexer. Configurez chacun d’entre eux avec un ensemble différent de valeurs de délai d’attente et de nouvelle tentative, comme décrit dans la section précédente, Que font les options de configuration StackExchange.Redis.

Comment puis-je évaluer et tester les performances de mon cache ?

Informations importantes sur la croissance du pool de threads

Le pool de threads CLR comporte deux types de threads : « Worker » et « I/O Completion Port » (IOCP).

  • Les threads de travail sont utilisés notamment pour le traitement des méthodes Task.Run(…) ou ThreadPool.QueueUserWorkItem(…). Ces threads sont également utilisés par différents composants dans le CLR lorsqu’une tâche doit être effectuée sur un thread en arrière-plan.
  • Les threads IOCP sont utilisés dans le cas d’E/S asynchrones, comme la lecture à partir du réseau.

Le pool de threads fournit de nouveaux threads Worker ou IOCP à la demande (sans aucune limitation) jusqu’à ce qu’il atteigne le paramètre « Minimum » pour chaque type de thread. Par défaut, le nombre minimal de threads est défini sur le nombre de processeurs d’un système.

Une fois que le nombre de threads existants (occupés) atteint le nombre « minimal » de threads, le pool de threads limite le taux d’injection des nouveaux threads à hauteur d’un thread toutes les 500 millisecondes. Généralement, si votre système reçoit une rafale de tâches nécessitant un thread IOCP, la tâche est traitée rapidement. Toutefois, si la rafale est supérieure au paramètre « Minimum » configuré, le traitement de certaines tâches sera retardé car le ThreadPool attendra l’une ou l’autre des possibilités :

  • Un thread existant se libère pour traiter la tâche.
  • Aucun thread existant ne se libère pendant 500 ms, auquel cas un nouveau thread est créé.

En fait, lorsque le nombre de threads occupés est supérieur au nombre minimum de threads, vous devrez probablement subir un délai de 500 ms avant que le trafic réseau ne soit traité par l’application. Lorsqu’un thread existant reste inactif pendant plus de 15 secondes, il est nettoyé et ce cycle de croissance et de diminution peut se répéter.

Observons cet exemple de message d’erreur de StackExchange.Redis (build 1.0.450 ou version ultérieure) ; vous voyez que les statistiques de pool de threads s’affichent désormais. Consultez les détails IOCP et WORKER ci-dessous.

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)

Dans l’exemple, vous pouvez voir que six threads sont occupés pour le thread IOCP et que le système est configuré pour autoriser au minimum quatre threads. Dans ce cas, le client constaterait deux retards de 500 ms, car 6 > 4.

Remarque

StackExchange.Redis peut atteindre les délais d’expiration si la croissance des threads IOCP ou WORKER est limitée.

Recommandation

Par conséquent, nous recommandons fortement aux clients de définir la valeur de configuration minimale pour les threads IOCP et WORKER sur une valeur supérieure à la valeur par défaut. Il est impossible de recommander une valeur unique car une valeur parfaitement adaptée à une application est certainement trop élevée ou trop faible pour une autre application. Ce paramètre peut également avoir un effet sur les performances d’autres composants d’applications complexes, ce qui signifie que chaque client doit ajuster ce paramètre en fonction de ses besoins spécifiques. Le mieux est de commencer à 200 ou 300, puis de tester et d’ajuster cette valeur en fonction des besoins.

Configuration de ce paramètre :

  • Nous vous recommandons de modifier ce paramètre programmatiquement à l’aide de la méthode ThreadPool.SetMinThreads (...) dans global.asax.cs. Par exemple :

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

    Notes

    La valeur spécifiée par cette méthode est un paramètre global qui affecte tout le domaine d’application. Par exemple, si vous avez une machine à quatre cœurs et que vous souhaitez définir minWorkerThreads et minIoThreads sur 50 par processeur pendant l’exécution, vous utiliserez ThreadPool.SetMinThreads(200, 200).

  • Il est également possible de spécifier le paramètre minimal de threads à l’aide du paramètre de configuration minIoThreads ou minWorkerThreads sous l’élément de configuration <processModel> dans Machine.config. Machine.config se trouve généralement dans %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. Définir le nombre minimal de threads de cette manière n’est pas recommandé, car il s’agit d’un paramètre à l’échelle du système.

    Notes

    La valeur spécifiée dans cet élément de configuration est un paramètre applicable par cœur. Par exemple, si vous utilisez un ordinateur à quatre cœurs et que vous souhaitez définir votre paramètre minIoThreads sur 200 au moment de l’exécution, vous utilisez <processModel minIoThreads="50"/>.

Activation de Garbage Collection sur le serveur pour obtenir un meilleur début sur le client lors de l'utilisation de StackExchange.Redis

L'activation de Garbage Collection sur le serveur peut optimiser le client, fournir des performances et un débit optimaux lors de l'utilisation de StackExchange.Redis. Pour plus d'informations sur Garbage Collection sur le serveur et son activation, consultez les articles suivants :

Considérations relatives aux performances de connexion

Différentes références SKU peuvent avoir des limites différentes pour les connexions clientes, la mémoire et la bande passante. Si chaque taille de cache autorise jusqu’à un certain nombre de connexions, chaque connexion à Redis entraîne une surcharge. Un exemple d’une telle surcharge est l’utilisation du processeur et de la mémoire en raison d’un chiffrement TLS/SSL. La limite maximale de connexions pour une taille de cache donnée suppose un cache peu chargé. Si la charge de la surcharge de connexion plus la charge des opérations de client dépasse la capacité du système, le cache peut rencontrer des problèmes de capacité, même si vous ne dépassez pas la limite de connexion pour la taille de cache actuelle.

Pour plus d’informations sur les différentes limites de connexion imposées sur chaque niveau, consultez la page Tarification d’Azure Managed Redis. Pour plus d’informations sur les connexions et les autres configurations par défaut, consultez la page Configuration du serveur Redis par défaut.

Étapes suivantes

En savoir plus sur d’autres FAQ sur Redis managé par Azure.