Lorsque vous représentez graphiquement le débit au fil du temps à mesure qu'une autre variable est modifiée, vous constatez généralement que le débit augmente jusqu'à ce qu'il atteigne un point d'épuisement des ressources.
La figure suivante montre un graphique typique de mise à l'échelle du débit. À mesure que le nombre de clients augmente, la charge de travail et le débit augmentent jusqu'à ce que toutes les ressources soient épuisées.
Idéalement, lorsque vous doublez la charge sur le système, le débit doit également doubler. En pratique, il y aura une contention des ressources qui entraînera une augmentation plus faible du débit. À un moment donné, l'épuisement ou la contention des ressources entraîneront une stabilisation, voire une diminution du débit. Si vous optimisez le débit, il s'agit d'un point clé à identifier, car il oriente vos efforts vers l'endroit où vous devez ajuster le système d'application ou de base de données pour améliorer le débit.
Voici quelques raisons courantes pour lesquelles le débit se stabilise ou diminue :
- Épuisement des ressources de processeur sur le serveur de base de données
- Épuisement des ressources de processeur sur le client, de sorte que le serveur de base de données ne reçoit plus de travail
- Contention de verrou de base de données
- Temps d'attente des E/S lorsque les données dépassent la taille du pool de mémoire tampon Postgres
- Temps d'attente des E/S en raison de l'utilisation du moteur de stockage
- Goulots d'étranglement de la bande passante réseau renvoyant des données au client
La latence et le débit sont inversement proportionnels. À mesure que la latence augmente, le débit diminue. Cela semble logique. Lorsqu'un goulot d'étranglement commence à se matérialiser, les opérations prennent plus de temps et le système effectue moins d'opérations par seconde.
Le graphique de mise à l'échelle de la latence montre comment la latence évolue à mesure que la charge placée sur un système augmente. La latence reste relativement constante jusqu'à ce que des frictions se produisent en raison de la contention des ressources. Le point d'inflexion de cette courbe correspond généralement à l'aplatissement de la courbe de débit dans le graphique de mise à l'échelle du débit.
Un histogramme est également un bon moyen d'évaluer la latence. Dans cette représentation, nous regroupons les latences dans des buckets et comptons le nombre de requêtes qui entrent dans chaque bucket.
Cet histogramme de latence montre que la plupart des requêtes sont inférieures à 100 millisecondes, et les latences supérieures à 100 millisecondes. Comprendre la cause des requêtes avec des latences de queue plus longues peut aider à expliquer les variations de performances de l'application observées. Les causes de la longue queue de latences accrues correspondent aux latences accrues observées dans le graphique de mise à l'échelle de la latence typique et à l'aplatissement du graphique du débit.
L'histogramme de latence est particulièrement utile lorsqu'une application comporte plusieurs modalités. Une modalité est un ensemble normal de conditions de fonctionnement. Par exemple, la plupart du temps, l'application accède à des pages qui se trouvent dans le cache du tampon. La plupart du temps, l'application met à jour les lignes existantes, mais il peut exister plusieurs modes. Parfois, l'application récupère des pages à partir du stockage, insère de nouvelles lignes ou rencontre des conflits de verrouillage.
Lorsqu'une application rencontre ces différents modes de fonctionnement au fil du temps, l'histogramme de latence affiche ces multiples modalités.
Cette figure montre un histogramme bimodal typique où la plupart des requêtes sont traitées en moins de 100 millisecondes, mais où un autre groupe de requêtes prend entre 401 et 500 millisecondes. Comprendre la cause de cette deuxième modalité peut vous aider à améliorer les performances de votre application. Il peut également y avoir plus de deux modalités.
La deuxième modalité peut être due à des opérations de base de données normales, à une infrastructure et une topologie hétérogènes, ou à un comportement d'application. Voici quelques exemples à prendre en considération :
- La plupart des accès aux données proviennent du pool de mémoire tampon PostgreSQL, mais certains proviennent du stockage.
- Différences de latence réseau pour certains clients vers le serveur de base de données
- Logique d'application qui effectue différentes opérations en fonction de l'entrée ou de l'heure de la journée
- Conflit de verrouillage sporadique
- Pics d'activité client