Deine API liefert unter Last Timeouts, aber die Datenbank-CPU ist niedrig und die Queries sehen schnell aus. Wo schaust du hin?

Diese Kombination deutet auf einen erschöpften Connection Pool oder ein ähnliches Concurrency-Limit hin, nicht auf eine langsame Datenbank. Prüf die Wartezeit im Pool und aktive gegen idle Verbindungen: Requests stehen für eine Verbindung an, während jeder Halter sie zu lange behält, oft wegen eines langsamen externen Aufrufs innerhalb einer Transaktion, eines fehlenden Timeouts oder einer geleakten Verbindung, die nie zurückgegeben wird. Behe zuerst die Haltezeit, dann dimensionier den Pool bewusst.

Schnelle Queries plus langsame Requests heißt, die Zeit geht fürs Warten auf irgendetwas drauf, und der Pool ist der übliche Verdächtige. Ich würde mir die Poolwartezeit ansehen und wie lange Verbindungen gehalten werden, dazu auf Datenbankseite die Zahl der aktiven gegen die idle-in-transaction-Sessions. Ein Haufen idle in transaction ist der Verräter: irgendetwas hat eine Transaktion geöffnet und dann Arbeit gemacht, die keine Datenbankarbeit ist. Das ist fast immer die Ursache, ein HTTP-Aufruf zu einem Payment-Provider oder ein langsamer Serialisierungsschritt mitten in einer Transaktion, jeder Request hält also eine Sekunde lang eine Verbindung statt fünf Millisekunden, und der Pool läuft bei einem Bruchteil des Traffics leer. Der Fix ist, den kritischen Abschnitt zu verkürzen: den externen Aufruf vor oder nach die Transaktion legen, Statement- und Transaktions-Timeouts setzen und sicherstellen, dass jeder Pfad seine Verbindung auch im Fehlerfall zurückgibt. Erst danach fasse ich die Größe an, und vorsichtig, weil jede Instanz sie multipliziert. Den Pool zu erhöhen, ohne die Haltezeit zu beheben, verschiebt die Warteschlange nur auf die Datenbank und macht aus einem langsamen Endpoint einen globalen Ausfall.