Questions fréquentes (FAQ) sur la gestion Redis managée Azure

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.

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

• Meilleures pratiques StackExchange.Redis
• Configuration et concepts
• Tests de performances

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

• N’oubliez pas que Redis est un magasin de données In-Memory . Pour plus d’informations, consultez Résoudre les problèmes de perte de données dans Azure Managed pour Redis afin de connaître les scénarios pouvant subir une perte de données.
• Développez votre système de telle sorte qu’il puisse gérer les problèmes de connexion causés par une mise à jour corrective et un basculement.

Tests de performances

• Consultez Tests de performances avec Azure Managed Redis pour obtenir des exemples de benchmarks et des instructions pour exécuter vos propres tests de performances sur Azure Managed Redis.

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 chacune 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 Des options de configuration StackExchange.Redis .

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

• Activez les diagnostics de cache afin de pouvoir surveiller l’état de votre cache. Vous pouvez afficher les mesures dans le portail Azure, et les télécharger et les analyser à l’aide des outils de votre choix.
• Consultez Tests de performances avec Azure Managed Redis pour obtenir des exemples de benchmarks et des instructions pour exécuter vos propres tests de performances sur Azure Managed Redis.

Informations importantes sur la croissance du pool de threads

Le threadPool CLR a deux types de threads : threads worker et port d’achèvement d’E/S (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 à Min threads, vous payez probablement un délai de 500 ms avant que l’application traite le trafic réseau. 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 du CIOP et du WORKER plus loin dans l’article.

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)

Comme illustré dans l’exemple, vous voyez que pour le thread IOCP, il existe six threads occupés et que le système est configuré pour autoriser quatre threads minimum. 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

Nous vous recommandons de définir la valeur de configuration minimale pour les threads IOCP et WORKER sur une valeur supérieure à la valeur par défaut. Nous ne pouvons pas donner de conseils d’une taille unique sur cette valeur, car la valeur appropriée pour une application peut être trop élevée ou faible pour une autre application. Ce paramètre peut également affecter les performances d’autres parties d’applications complexes. Chaque client doit ajuster ce paramètre à 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 par programmation à l’aide de la méthode ThreadPool.SetMinThreads (...) dans les applications .NET Framework et .NET Core.

Par exemple, dans NET Framework, vous l’avez définie dans Global.asax.cs la Application_Start méthode :

```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 vous utilisez .NET Core, vous l’avez défini dans Program.cs, juste avant l’appel :WebApplication.CreateBuilder()

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Remarque

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 avec quatre cœurs et que vous souhaitez définir minWorkerThreads et minIoThreads atteindre 50 par processeur pendant l’exécution, utilisez ThreadPool.SetMinThreads(200, 200).

Il est également possible de spécifier le paramètre de threads minimal à l’aide du minIoThreads paramètre de configuration ou minWorkerThreads du paramètre de configuration sous l’élément <processModel> de configuration dans .Machine.config Machine.config se trouve généralement dans %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\.

Il n’est pas recommandé de définir le nombre minimum de threads de cette manière, car il s’agit d’un paramètre à l’échelle du système. Si vous le définissez de cette façon, vous devez redémarrer le pool d’applications.

Remarque

La valeur spécifiée dans cet élément de configuration est un paramètre applicable par cœur. Par exemple, si vous avez un ordinateur à quatre cœurs et que votre minIoThreads paramètre doit être 200 lors de l’exécution, 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 :

• Activation de Garbage Collection sur le serveur
• Les principes fondamentaux de la collecte de déchets
• Garbage Collection et performances

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. Bien que chaque taille de cache autorise jusqu’à un certain nombre de connexions, chaque connexion à Redis a une surcharge associée. 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.

Contenu connexe

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

Cet article fournit des réponses aux questions fréquentes sur la gestion d’Azure Managed 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.

• Meilleures pratiques StackExchange.Redis
• Configuration et concepts
• Tests de performances

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

• N’oubliez pas que Redis est un magasin de données In-Memory . Pour plus d’informations, consultez Résoudre les problèmes de perte de données dans Azure Managed pour Redis afin de connaître les scénarios pouvant subir une perte de données.
• Développez votre système de telle sorte qu’il puisse gérer les problèmes de connexion causés par une mise à jour corrective et un basculement.

Tests de performances

• Consultez Tests de performances avec Azure Managed Redis pour obtenir des exemples de benchmarks et des instructions pour exécuter vos propres tests de performances sur Azure Managed Redis.

• É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 chacune 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 Des options de configuration StackExchange.Redis .

• Activez les diagnostics de cache afin de pouvoir surveiller l’état de votre cache. Vous pouvez afficher les mesures dans le portail Azure, et les télécharger et les analyser à l’aide des outils de votre choix.
• Consultez Tests de performances avec Azure Managed Redis pour obtenir des exemples de benchmarks et des instructions pour exécuter vos propres tests de performances sur Azure Managed Redis.

Le threadPool CLR a deux types de threads : threads worker et port d’achèvement d’E/S (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 à Min threads, vous payez probablement un délai de 500 ms avant que l’application traite le trafic réseau. 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 du CIOP et du WORKER plus loin dans l’article.

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)

Comme illustré dans l’exemple, vous voyez que pour le thread IOCP, il existe six threads occupés et que le système est configuré pour autoriser quatre threads minimum. 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

Nous vous recommandons de définir la valeur de configuration minimale pour les threads IOCP et WORKER sur une valeur supérieure à la valeur par défaut. Nous ne pouvons pas donner de conseils d’une taille unique sur cette valeur, car la valeur appropriée pour une application peut être trop élevée ou faible pour une autre application. Ce paramètre peut également affecter les performances d’autres parties d’applications complexes. Chaque client doit ajuster ce paramètre à 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 par programmation à l’aide de la méthode ThreadPool.SetMinThreads (...) dans les applications .NET Framework et .NET Core.

Par exemple, dans NET Framework, vous l’avez définie dans Global.asax.cs la Application_Start méthode :

```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 vous utilisez .NET Core, vous l’avez défini dans Program.cs, juste avant l’appel :WebApplication.CreateBuilder()

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Remarque

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 avec quatre cœurs et que vous souhaitez définir minWorkerThreads et minIoThreads atteindre 50 par processeur pendant l’exécution, utilisez ThreadPool.SetMinThreads(200, 200).

Il est également possible de spécifier le paramètre de threads minimal à l’aide du minIoThreads paramètre de configuration ou minWorkerThreads du paramètre de configuration sous l’élément <processModel> de configuration dans .Machine.config Machine.config se trouve généralement dans %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\.

Il n’est pas recommandé de définir le nombre minimum de threads de cette manière, car il s’agit d’un paramètre à l’échelle du système. Si vous le définissez de cette façon, vous devez redémarrer le pool d’applications.

Remarque

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

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 :

• Activation de Garbage Collection sur le serveur
• Les principes fondamentaux de la collecte de déchets
• Garbage Collection et performances

Différentes références SKU peuvent avoir des limites différentes pour les connexions clientes, la mémoire et la bande passante. Bien que chaque taille de cache autorise jusqu’à un certain nombre de connexions, chaque connexion à Redis a une surcharge associée. 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.

Contenu connexe

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