Quand je tombe sur une lenteur, j'écris d'abord trois choses : ce que j'instrumente, ce que je compare, et ce qui me ferait abandonner mon hypothèse. Dix minutes. Sans ça, je pars sur la première piste qui a l'air logique, et ça ne veut pas dire que c'est la bonne.
Trois exemples.
L'export de 44 secondes
Un export mettait 44 secondes. J'ai mesuré avant de supposer : plus de 42 secondes se passaient côté application, avant même l'appel au service. Le service, lui, répondait en un peu plus d'une seconde.
Le coupable : des requêtes en cascade. Un exemple générique, ce n'est pas le code d'origine :
# 1 requête pour les comptes, puis 1 par compte
accounts.each { |a| puts a.employees.count }
# 2 requêtes, quel que soit le nombre de comptes
accounts.includes(:employees).each { |a| puts a.employees.size }
Les plus gros comptes
Une autre lenteur, uniquement sur les très gros comptes. Je suis reparti de zéro : j'ai instrumenté le front et le back, puis comparé trois tailles de compte. Ce qui grossit avec le compte, c'est le goulot.
J'ai corrigé les requêtes en cascade plutôt que d'ajouter du cache, parce qu'un cache masque le problème sans le régler. Le correctif backend est en production, et j'ai recensé les autres endroits qui avaient le même défaut.
Le bug d'affichage
Ça ressemblait à un bug d'interface. En remontant, c'était un contournement d'une règle métier. Ce qui a tranché : aucune vue de l'application ne permet de créer cet état à la main, donc il venait d'ailleurs. Le sujet n'était plus l'affichage, c'était une décision à prendre un niveau au-dessus.
Et si une analyse que j'ai postée se révèle fausse, je la corrige au même endroit.
Le reste de ma façon de travailler est sur amineaffif.com/methode.
Amine Affif, développeur full-stack à Paris.
English version: A 44-second export: measure before you look
Top comments (0)