Un endpoint qui prenait 80 millisecondes en met maintenant quatre secondes en production. Comment trouveriez-vous la cause ?

Mesurez avant de deviner. Établissez si c'est lent pour tout le monde ou pour un seul compte, puis lisez une trace pour voir où le temps se trouve réellement : code applicatif, base de données, ou appel sortant. Le plus souvent c'est la base, donc sortez le journal des requêtes lentes et lancez EXPLAIN ANALYZE sur la requête suspecte. En parallèle, regardez ce qui a changé, puisqu'un déploiement, un seuil de volume de données, ou un cache qui a cessé de fonctionner expliquent la plupart des régressions.

D'abord je veux la forme du problème. Est-ce chaque requête ou le quatre-vingt-dix-neuvième percentile, un locataire ou tous, et quand exactement ça a commencé. Cet horodatage résout souvent la moitié de l'affaire tout seul, parce qu'il s'aligne sur un déploiement, une migration ou un changement de configuration. Ensuite je récupère une trace pour une requête lente et je regarde la cascade, puisque deviner quelle couche est lente est la plus grosse perte de temps. Si c'est la base, je regarde le journal des requêtes lentes et je lance EXPLAIN ANALYZE, et les réponses courantes sont un basculement de plan après la croissance de la table, un index manquant sur une colonne nouvellement filtrée, ou un N plus un qui ne fait mal que maintenant que les comptes ont plus de lignes. Si c'est un appel sortant, je vérifie si cette dépendance est dégradée et si nous avons un timeout tout court, parce qu'un timeout manquant transforme leur mauvaise journée en la nôtre. En attendant, si des utilisateurs souffrent, j'atténue d'abord : retour arrière, ajout d'un cache court, ou délestage du chemin coûteux, puis je termine le diagnostic sans la pression.