FAQ de la gestion du cache

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

Important

Azure Cache pour Redis a annoncé sa chronologie de mise hors service pour toutes les références SKU. Nous vous recommandons de déplacer vos instances Azure Cache pour Redis existantes vers Azure Managed Redis dès que vous le pouvez.

Pour plus d’informations sur la mise hors service :

• Mise hors service d’Azure Cache pour Redis : ce qu’il faut savoir et comment s’y préparer
• Faq sur la mise hors service d’Azure Cache pour Redis

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

• Utilisez redis-benchmark.exe pour tester la charge de votre serveur Redis. Utilisez redis-benchmark.exe pour avoir une idée du débit possible avant d’effectuer vos propres tests de performances.
• Permet redis-cli de surveiller le cache à l’aide de la commande INFO. Pour obtenir des instructions sur le téléchargement des outils Redis, consultez la Comment exécuter des commandes Redis ?.
• Si vous utilisez TLS/SSL (Transport Layer Security/Secure Socket Layer) sur votre instance de cache, ajoutez le paramètre --tls à vos commandes des outils Redis ou utilisez un proxy comme stunnel pour activer TLS/SSL.
• Redis-benchmark utilise le port 6379 par défaut. Utilisez le paramètre -p pour remplacer ce paramètre si votre cache utilise le port 6380 SSL/TLS ou le port de niveau Entreprise 10000.
• Si nécessaire, vous pouvez activer le port non TLS via le Portail Azure avant d’exécuter le test de charge.
• Assurez-vous que la machine virtuelle cliente que vous utilisez pour le test se trouve dans la même région que votre instance de Azure Cache pour Redis.
• Assurez-vous que votre machine virtuelle cliente que vous choisissez présente au moins autant de puissance de calcul et de bande passante que le cache que vous testez. Pour de meilleurs résultats, utilisez les machines virtuelles des séries D et E pour vos clients.
• Si vous êtes sur Windows, activez la mise à l’échelle côté réception virtuelle (VRSS) sur l’ordinateur client. Pour plus d’informations, voir vRSS dans Windows Server 2012 R2.
• Activez les diagnostics du cache afin de pouvoir surveiller l’intégrité de votre cache. Vous pouvez afficher les mesures dans le portail Azure, et télécharger et analyser vos métriques à l’aide des outils de votre choix.
• Si votre charge provoque une fragmentation élevée de la mémoire, augmentez la taille de votre cache.

Les exemples suivants montrent comment utiliser redis-benchmark.exe. Pour obtenir des résultats précis, exécutez ces commandes à partir d’une machine virtuelle située dans la même région que votre cache.

Testez d’abord des requêtes SET en pipeline à l’aide d’une charge utile de 1 ko :

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

Après avoir exécuté le test SET, exécutez des requêtes GET pipeline à l’aide d’une charge utile de 1 000 :

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

Comment puis-je activer le nettoyage de la mémoire (GC) du serveur pour obtenir un meilleur débit sur le client lors de l’utilisation de StackExchange.Redis?

L'activation de GC 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 :

• L’élément <gcServer>
• Principes de base du GC
• GC et performances

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

Le serveur Redis ne prend pas en charge TLS (Transport Layer Security) en mode natif, mais Azure Cache pour Redis prend en charge TLS. Si vous vous connectez à Azure Cache pour Redis avec un client comme StackExchange.Redis qui prend en charge TLS, utilisez TLS.

Remarque

Le port non TLS est désactivé par défaut pour les nouvelles instances Azure Redis. Si votre client ne prend pas en charge TLS, activez le port non TLS en suivant les instructions des ports Access.

Si le cache utilise TLS, vous devez activer TLS à l’aide de l’option pour les outils --tls Redis tels que redis-cli. Vous pouvez également utiliser un utilitaire comme stunnel pour connecter sans problème les outils au port TLS en suivant les instructions du billet de blog Announcing ASP.NET Session State Provider for Redis Preview Release.

Pour obtenir des instructions sur le téléchargement des outils Redis, consultez la Comment exécuter des commandes Redis ?.

Quelles sont les considérations à prendre en compte pour l’utilisation de commandes Redis 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. Redis est un serveur à thread unique qui traite une commande à la fois. Si vous émettez la commande KEYS, Redis ne traite pas les commandes suivantes tant qu’elle n’a pas terminé le traitement de la commande KEYS.

  Le site redis.io a des détails de complexité temporelle pour chaque opération qu’il prend en charge. Sélectionnez chaque commande pour voir la complexité de chaque opération.

• La taille des clés à utiliser 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 de clés les plus petites donnent de meilleures performances.

• Ces considérations ne signifient pas que vous ne pouvez pas stocker de valeurs plus grandes dans Redis, mais les latences sont plus élevées. Si vous avez un jeu de données plus volumineux qu’un autre, vous pouvez utiliser plusieurs instances ConnectionMultiplexer, chacune configurée avec un ensemble différent de valeurs de délai d’expiration et de nouvelles tentatives. Pour plus d’informations, consultez Que font les options de configuration StackExchange.Redis ?

Quelles sont les considérations relatives aux performances des connexions ?

Chaque niveau tarifaire Azure Cache pour Redis a 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 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 du Cache Azure pour 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.

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

• Utilisez le niveau Standard ou Premium pour les systèmes de production. Le niveau De base est un système à nœud unique sans réplication des données et sans contrat de niveau de service (SLA). Utilisez également au moins un cache C1 pour la production. Les caches C0 s’appliquent généralement aux scénarios de développement/test simples.
• N’oubliez pas que Redis est un magasin de données en mémoire et que des pertes de données peuvent se produire dans certains scénarios. Pour plus d’informations, consultez Résolution des problèmes de perte de données dans Azure Cache pour Redis.
• Développez votre système de telle sorte qu’il puisse gérer les problèmes de connexion liés à une mise à jour corrective et à un basculement.
• Utilisez les instances Azure Redis de niveau Premium pour bénéficier d'une meilleure latence réseau et d'un meilleur débit, car elles disposent d'un matériel plus performant tant au niveau du processeur que du réseau.

Meilleures pratiques StackExchange.Redis

• Définissez la valeur AbortConnect faux, puis laissez 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. Par exemple, dans Quelle est la plage de taille de valeur idéale pour redis ?, 100 Ko est considéré comme volumineux. Pour plus d’informations, consultez Envisager plus de clés et de valeurs plus petites.
• 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 contient des détails sur la complexité temporelle de chaque opération qu’il prend en charge. Sélectionnez chaque commande pour voir la complexité de chaque opération.

Informations importantes sur la croissance du pool de threads

Le pool de threads CLR (Common Language Runtime) a deux types de threads, Worker et IOCP (I/O Completion Port).

• Les threads WORKER de travail sont utilisés notamment pour le traitement des méthodes Task.Run(…) ou ThreadPool.QueueUserWorkItem(…). Divers composants du CLR utilisent également ces threads lorsque des tâches doivent être effectuées dans un thread d'arrière-plan.
• Les threads IOCP sont utilisés pour les E/S asynchrones, par exemple lors de 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 threads existants (occupés) atteint le nombre de threads minimum, 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 Busy est supérieur Min à celui des threads, vous rencontrez 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.

Les messages d’erreur de StackExchange.Redis build 1.0.450 ou version ultérieure impriment les statistiques ThreadPool, comme illustré dans l’exemple suivant.

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)

L’exemple montre 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 est susceptible de voir deux retards de 500 ms, car 6 > 4.

Remarque

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

Il est préférable 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 n’existe aucun guide de taille unique sur cette valeur, car la valeur appropriée pour une application est probablement trop élevée ou faible pour une autre application. Ce paramètre peut également affecter les performances d’autres parties d’applications complexes. Vous devez ajuster ce paramètre à vos besoins spécifiques. Un bon point de départ est 200 ou 300. Ensuite, testez et ajustez en fonction des besoins.

Configurer le paramètre minimum de threads

Vous pouvez modifier ce paramètre programmatiquement à l’aide de la méthode ThreadPool.SetMinThreads (...) dans.

Par exemple, dans NET Framework, vous définissez cette valeur dans Global.asax.cs dans la méthode 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 vous utilisez .NET Core, vous définissez la valeur dans Program.cs juste avant l’appel à WebApplication.CreateBuilder() :

    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 disposez d’une machine virtuelle à quatre cœurs et que vous souhaitez définir et que vous souhaitez définir minWorkerThreads et minIoThreads la valeur 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 ou du minWorkerThreadsparamètre de configuration ou sous l’élément de configuration <processModel> dans Machine.config. Machine.config se trouve généralement à l’emplacement %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. Si vous définissez des threads minimaux de cette façon, vous devez redémarrer le pool d’applications.

Remarque

La valeur spécifiée par cette méthode est un paramètre par cœur. Par exemple, si vous disposez d’un ordinateur à quatre cœurs et que vous souhaitez que votre paramètre minIoThreads soit 200 au moment de l’exécution, utilisez <processModel minIoThreads="50">.

Contenu connexe

• Consultez d’autres FAQ sur les Azure Cache pour Redis.

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

Important

Azure Cache pour Redis a annoncé sa chronologie de mise hors service pour toutes les références SKU. Nous vous recommandons de déplacer vos instances Azure Cache pour Redis existantes vers Azure Managed Redis dès que vous le pouvez.

Pour plus d’informations sur la mise hors service :

• Mise hors service d’Azure Cache pour Redis : ce qu’il faut savoir et comment s’y préparer
• Faq sur la mise hors service d’Azure Cache pour Redis

• Utilisez redis-benchmark.exe pour tester la charge de votre serveur Redis. Utilisez redis-benchmark.exe pour avoir une idée du débit possible avant d’effectuer vos propres tests de performances.
• Permet redis-cli de surveiller le cache à l’aide de la commande INFO. Pour obtenir des instructions sur le téléchargement des outils Redis, consultez la Comment exécuter des commandes Redis ?.
• Si vous utilisez TLS/SSL (Transport Layer Security/Secure Socket Layer) sur votre instance de cache, ajoutez le paramètre --tls à vos commandes des outils Redis ou utilisez un proxy comme stunnel pour activer TLS/SSL.
• Redis-benchmark utilise le port 6379 par défaut. Utilisez le paramètre -p pour remplacer ce paramètre si votre cache utilise le port 6380 SSL/TLS ou le port de niveau Entreprise 10000.
• Si nécessaire, vous pouvez activer le port non TLS via le Portail Azure avant d’exécuter le test de charge.
• Assurez-vous que la machine virtuelle cliente que vous utilisez pour le test se trouve dans la même région que votre instance de Azure Cache pour Redis.
• Assurez-vous que votre machine virtuelle cliente que vous choisissez présente au moins autant de puissance de calcul et de bande passante que le cache que vous testez. Pour de meilleurs résultats, utilisez les machines virtuelles des séries D et E pour vos clients.
• Si vous êtes sur Windows, activez la mise à l’échelle côté réception virtuelle (VRSS) sur l’ordinateur client. Pour plus d’informations, voir vRSS dans Windows Server 2012 R2.
• Activez les diagnostics du cache afin de pouvoir surveiller l’intégrité de votre cache. Vous pouvez afficher les mesures dans le portail Azure, et télécharger et analyser vos métriques à l’aide des outils de votre choix.
• Si votre charge provoque une fragmentation élevée de la mémoire, augmentez la taille de votre cache.

Les exemples suivants montrent comment utiliser redis-benchmark.exe. Pour obtenir des résultats précis, exécutez ces commandes à partir d’une machine virtuelle située dans la même région que votre cache.

Testez d’abord des requêtes SET en pipeline à l’aide d’une charge utile de 1 ko :

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

Après avoir exécuté le test SET, exécutez des requêtes GET pipeline à l’aide d’une charge utile de 1 000 :

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

L'activation de GC 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 :

• L’élément <gcServer>
• Principes de base du GC
• GC et performances

Le serveur Redis ne prend pas en charge TLS (Transport Layer Security) en mode natif, mais Azure Cache pour Redis prend en charge TLS. Si vous vous connectez à Azure Cache pour Redis avec un client comme StackExchange.Redis qui prend en charge TLS, utilisez TLS.

Remarque

Le port non TLS est désactivé par défaut pour les nouvelles instances Azure Redis. Si votre client ne prend pas en charge TLS, activez le port non TLS en suivant les instructions des ports Access.

Si le cache utilise TLS, vous devez activer TLS à l’aide de l’option pour les outils --tls Redis tels que redis-cli. Vous pouvez également utiliser un utilitaire comme stunnel pour connecter sans problème les outils au port TLS en suivant les instructions du billet de blog Announcing ASP.NET Session State Provider for Redis Preview Release.

Pour obtenir des instructions sur le téléchargement des outils Redis, consultez la Comment exécuter des commandes 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. Redis est un serveur à thread unique qui traite une commande à la fois. Si vous émettez la commande KEYS, Redis ne traite pas les commandes suivantes tant qu’elle n’a pas terminé le traitement de la commande KEYS.

  Le site redis.io a des détails de complexité temporelle pour chaque opération qu’il prend en charge. Sélectionnez chaque commande pour voir la complexité de chaque opération.

• La taille des clés à utiliser 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 de clés les plus petites donnent de meilleures performances.

• Ces considérations ne signifient pas que vous ne pouvez pas stocker de valeurs plus grandes dans Redis, mais les latences sont plus élevées. Si vous avez un jeu de données plus volumineux qu’un autre, vous pouvez utiliser plusieurs instances ConnectionMultiplexer, chacune configurée avec un ensemble différent de valeurs de délai d’expiration et de nouvelles tentatives. Pour plus d’informations, consultez Que font les options de configuration StackExchange.Redis ?

Chaque niveau tarifaire Azure Cache pour Redis a 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 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 du Cache Azure pour 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.

• Utilisez le niveau Standard ou Premium pour les systèmes de production. Le niveau De base est un système à nœud unique sans réplication des données et sans contrat de niveau de service (SLA). Utilisez également au moins un cache C1 pour la production. Les caches C0 s’appliquent généralement aux scénarios de développement/test simples.
• N’oubliez pas que Redis est un magasin de données en mémoire et que des pertes de données peuvent se produire dans certains scénarios. Pour plus d’informations, consultez Résolution des problèmes de perte de données dans Azure Cache pour Redis.
• Développez votre système de telle sorte qu’il puisse gérer les problèmes de connexion liés à une mise à jour corrective et à un basculement.
• Utilisez les instances Azure Redis de niveau Premium pour bénéficier d'une meilleure latence réseau et d'un meilleur débit, car elles disposent d'un matériel plus performant tant au niveau du processeur que du réseau.

Meilleures pratiques StackExchange.Redis

• Définissez la valeur AbortConnect faux, puis laissez 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. Par exemple, dans Quelle est la plage de taille de valeur idéale pour redis ?, 100 Ko est considéré comme volumineux. Pour plus d’informations, consultez Envisager plus de clés et de valeurs plus petites.
• 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 contient des détails sur la complexité temporelle de chaque opération qu’il prend en charge. Sélectionnez chaque commande pour voir la complexité de chaque opération.

Le pool de threads CLR (Common Language Runtime) a deux types de threads, Worker et IOCP (I/O Completion Port).

• Les threads WORKER de travail sont utilisés notamment pour le traitement des méthodes Task.Run(…) ou ThreadPool.QueueUserWorkItem(…). Divers composants du CLR utilisent également ces threads lorsque des tâches doivent être effectuées dans un thread d'arrière-plan.
• Les threads IOCP sont utilisés pour les E/S asynchrones, par exemple lors de 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 threads existants (occupés) atteint le nombre de threads minimum, 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 Busy est supérieur Min à celui des threads, vous rencontrez 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.

Les messages d’erreur de StackExchange.Redis build 1.0.450 ou version ultérieure impriment les statistiques ThreadPool, comme illustré dans l’exemple suivant.

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)

L’exemple montre 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 est susceptible de voir deux retards de 500 ms, car 6 > 4.

Remarque

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

Il est préférable 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 n’existe aucun guide de taille unique sur cette valeur, car la valeur appropriée pour une application est probablement trop élevée ou faible pour une autre application. Ce paramètre peut également affecter les performances d’autres parties d’applications complexes. Vous devez ajuster ce paramètre à vos besoins spécifiques. Un bon point de départ est 200 ou 300. Ensuite, testez et ajustez en fonction des besoins.

Configurer le paramètre minimum de threads

Vous pouvez modifier ce paramètre programmatiquement à l’aide de la méthode ThreadPool.SetMinThreads (...) dans.

Par exemple, dans NET Framework, vous définissez cette valeur dans Global.asax.cs dans la méthode 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 vous utilisez .NET Core, vous définissez la valeur dans Program.cs juste avant l’appel à WebApplication.CreateBuilder() :

    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 disposez d’une machine virtuelle à quatre cœurs et que vous souhaitez définir et que vous souhaitez définir minWorkerThreads et minIoThreads la valeur 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 ou du minWorkerThreadsparamètre de configuration ou sous l’élément de configuration <processModel> dans Machine.config. Machine.config se trouve généralement à l’emplacement %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. Si vous définissez des threads minimaux de cette façon, vous devez redémarrer le pool d’applications.

Remarque

La valeur spécifiée par cette méthode est un paramètre par cœur. Par exemple, si vous disposez d’un ordinateur à quatre cœurs et que vous souhaitez que votre paramètre minIoThreads soit 200 au moment de l’exécution, utilisez <processModel minIoThreads="50">.

Contenu connexe

• Consultez d’autres FAQ sur les Azure Cache pour Redis.