Graphique de latence redis

Redis est un magasin de données en mémoire largement utilisé qui est bien optimisé pour des performances plus élevées. Sa vitesse le rend utile pour les applications en temps réel, la mise en cache et le stockage de session. Dans le même temps, Redis propose plusieurs commandes qui sont rapides et optimisées. Pourtant, certaines commandes redis prennent une complexité de temps plus lente. La nature unique de Redis soulève également des problèmes de latence. La latence Redis peut être classée en trois domaines principaux: latence du client, la latence de commandement et la latence aller-retour.

Latence du client

Redis est livré avec une architecture client-serveur. Dans certains cas, plusieurs clients peuvent essayer de se connecter simultanément au serveur Redis. Étant donné que Redis est unique, cela introduira une file d'attente client où le serveur sert un processus client à un moment donné. Par conséquent, la latence de la concurrence est née. Par conséquent, les clients successifs pourraient avoir besoin d'attendre.

Latence de commandement

Chaque commande prend du temps pour exécuter. Il peut varier de la microseconde aux secondes. Par conséquent, il a été identifié comme une source de latence. La plupart des commandes redis prennent une complexité temporelle constante ou logarithmique. En même temps, certaines commandes prennent une complexité de temps (n). Ils sont considérablement plus lents.

Latence aller-retour

L'intérieur est le temps nécessaire pour obtenir une réponse du serveur Redis une fois qu'une commande a été exécutée sur le côté client. Il peut y avoir différentes causes de latence aller-retour, comme la lenteur du réseau, les opérations de fourche et la pagination du système d'exploitation.

Surveillance de la latence redis

Les applications en temps réel utilisent Redis, où les performances sont cruciales. Par conséquent, il est gratifiant d'avoir des informations sur la latence redis qui sera utile pour prendre des mesures à l'avance. De la version 2.8.13, Redis a ajouté le composant de surveillance de latence à sa boîte à outils. Ce composant est capable d'enregistrer des pointes de latence par événement ou un chemin de code spécifique.

Événements de latence ou chemins de code

Les événements de latence (chemins de code) ne sont rien de plus que les opérations génériques ou spécifiques effectuées par Redis, telles que les commandes génériques, les appels du système de fourche et les systèmes de non-link. En ce qui concerne les commandes génériques, il y a deux événements principaux définis par redis.

1. commande
2. commande rapide

L'événement «Fast Command» est défini pour les commandes redis qui ont o (1) ou o (log n) complexité temporelle, comme HSET, Hincrby, Hlen, etc.

Le chemin de code «Commande» mesure les pointes de latence pour les autres commandes avec une complexité temporelle O (n).

Activation de la surveillance de latence dans Redis Server

Les valeurs de latence dépendent de la nature de l'application. Une application peut considérer 10 millisecondes comme une latence élevée. En même temps, une autre application considère 1 seconde comme une valeur élevée. Par conséquent, Redis vous offre une option pour définir le seuil de latence dans le serveur. Par défaut, la valeur de seuil est 0. Il existe deux façons de définir cette valeur dans Redis:

1. Utilisation de la sous-commande «config set» dans l'exécution
2. Modification du fichier de configuration redis

La sous-commande de configuration
Vous pouvez utiliser la sous-commande de configuration de configuration avec le paramètre et sa valeur pour définir la valeur de seuil, comme indiqué dans ce qui suit. Ici, nous l'avons réglé comme 500 millisecondes.

config définir la latence-monitor-threshold 500

Modification du redis.fichier de confr
Nous pouvons démarrer le serveur Redis en fournissant toutes les configurations dans un fichier de configuration appelé «redis.conf. Dans la section «Moniteur de latence», vous pouvez définir la valeur du paramètre «latence-monitor-threshold» en conséquence.

Il est recommandé de redémarrer le serveur Redis après avoir modifié le fichier de configuration.

La sous-commande graphique de latence

La commande «latence» propose plusieurs sous-commandes pour récupérer des informations de latence basées sur des événements. L'une des commandes populaires est le «graphique de latence». Il dessine un graphique contre le moment où l'événement s'est produit. Ce graphique est basé sur les symboles ASCII et va de la valeur de latence minimale à maximum. Les pointes de latence sont normalisées entre les latences min et max.

Utilisons la commande «Debug Sleep» pour vérifier comment les informations du graphique de latence sont générées.

Syntaxe

La latence

Le paramètre «Event_name» peut être tout événement défini par le cadre de surveillance de la latence Redis, tel que la commande, la commande rapide, la fourche, etc.

Exemple 01 - Applications avec latence sous le seuil

Utilisons la commande «Debug Sleep» pour générer des pics de latence. Il ira dormir jusqu'à l'emploi spécifié. Étant donné que le seuil de latence est de 500 ms, nous émettons des commandes de sommeil avec un délai inférieur à 500 ms.

déboguer le sommeil .1
déboguer le sommeil .2
déboguer le sommeil .3

Ensuite, nous émettons la commande du graphique de latence comme indiqué dans ce qui suit:

Commande de graphique de latence

Cela générerait idéalement le graphique de latence de style ASCII pour les commandes précédentes. Étant donné que le temps d'exécution des commandes est inférieur à la valeur de seuil dans les trois commandes «de débogage de sommeil», Redis ne générera pas de pics de latence. Si nous supposons que c'est notre application en temps réel, vous êtes tous bons. Il n'y a aucun problème de latence joint.

Sortir:

Comme prévu, il indique qu'aucun échantillon n'est disponible pour cet événement particulier.

Exemple 02 - Applications avec latence supérieure au seuil

Émettrons certaines commandes de débogage avec une valeur de délai supérieur à la valeur de seuil. Habituellement, il est préférable de réinitialiser toutes les pics de latence précédents avant le prochain ensemble de commandes, comme indiqué dans les éléments suivants:

Commande de réinitialisation de latence

Ensuite, nous émettons les commandes de sommeil de débogage avec une valeur de délai d'expiration de plus de 500 ms.

déboguer le sommeil .7
déboguer le sommeil .9
déboguer le sommeil 1

Sortir:

Comme prévu, le graphique de style ascii a été généré par redis. Le «_» indique la valeur la plus basse de latence, et le symbole «#» désigne la pointe la latence la plus élevée qui s'est produite dans les 20 dernières secondes. Ce graphique peut être interprété verticalement. Chaque colonne est pour un événement qui s'est produit dans les dernières secondes, minutes ou jours. La colonne la plus à gauche peut être interprétée comme l'événement qui s'est produit il y a 20 secondes, le suivant s'est produit il y a 14 secondes, et la dernière colonne désigne un événement qui s'est produit il y a 4 secondes.

Conclusion

Redis est utilisé comme magasin de données pour des applications en temps réel. Par conséquent, les aspects de performance sont cruciaux. Le cadre de surveillance de latence est un composant proposé par Redis pour surveiller les pics de latence pour les événements prédéfinis. La «Commande de graphique de latence» peut être utilisée pour générer les pics de latence de style ASCII pour un délai donné. Il est utilisé pour identifier les tendances de latence de votre application et prendre les mesures nécessaires à l'avance. Les pics de latence seront générés si le temps de latence est supérieur à la valeur de seuil. La valeur de seuil de latence peut différer d'une application à une autre en fonction de la nature.