Votre API se met à renvoyer des expirations sous charge, mais le CPU de la base est bas et les requêtes semblent rapides. Où regardez-vous ?

Cette combinaison pointe vers un épuisement du pool de connexions ou une limite de concurrence similaire, pas vers une base lente. Regardez le temps d'attente du pool et les connexions actives contre inactives : les requêtes font la queue pour une connexion pendant que chaque détenteur la garde trop longtemps, souvent à cause d'un appel externe lent dans une transaction, d'un délai d'expiration manquant, ou d'une connexion fuitée jamais rendue. Corrigez d'abord la durée de détention, puis dimensionnez le pool délibérément.

Des requêtes rapides plus des demandes lentes signifient que le temps est passé à attendre quelque chose, et le pool est le suspect habituel. Je regarderais le temps d'attente du pool et la durée de détention des connexions, plus le comptage côté base des sessions actives contre idle in transaction. Un tas de idle in transaction est révélateur : quelque chose a ouvert une transaction puis a fait un travail qui n'est pas du travail de base de données. C'est presque toujours la cause, un appel HTTP à un prestataire de paiement ou une sérialisation lente à l'intérieur d'une transaction, donc chaque requête garde une connexion une seconde au lieu de cinq millisecondes et le pool se vide à une fraction du trafic. La correction consiste à raccourcir la section critique : faire l'appel externe avant ou après la transaction, ajouter des délais d'expiration au niveau instruction et transaction, et s'assurer que chaque chemin rend sa connexion même en cas d'erreur. Seulement ensuite je toucherais à la taille, et prudemment, parce que chaque instance la multiplie. Augmenter le pool sans corriger la durée de détention ne fait que déplacer la file vers la base et transforme un endpoint lent en panne globale.