A 44-second export: measure before you look

Amine Affif — Sun, 04 Oct 2026 18:26:20 +0000

When I hit a slowdown, I write three things down first: what I instrument, what I compare, and what would make me drop my hypothesis. Ten minutes. Without it, I follow the first lead that looks logical, and that doesn't make it the right one.

Three examples.

The 44-second export

An export took 44 seconds. I measured before assuming: more than 42 seconds were spent in the application, before the call to the service even started. The service itself answered in a little over a second.

The culprit: cascading queries. A generic example, not the original code:

# 1 query for the accounts, then 1 per account
accounts.each { |a| puts a.employees.count }

# 2 queries, whatever the number of accounts
accounts.includes(:employees).each { |a| puts a.employees.size }

The biggest accounts

Another slowdown, only on the very large accounts. I started over: I instrumented the front end and the back end, then compared three account sizes. What grows with the account is the bottleneck.

I fixed the cascading queries instead of adding a cache, because a cache hides the problem without solving it. The backend fix is in production, and I went through the other places with the same flaw.

The display bug

It looked like a UI bug. Digging back, it was a business rule being bypassed. What settled it: no screen in the app lets you create that state by hand, so it came from somewhere else. The subject was no longer the display, it was a decision for someone a level up.

And if an analysis I posted turns out to be wrong, I correct it in the same place.

The rest of how I work is at amineaffif.com/en/methode.

Amine Affif, full-stack developer in Paris.

Version française : Un export de 44 secondes : mesurer avant de chercher

Un export de 44 secondes : mesurer avant de chercher

Amine Affif — Sun, 04 Oct 2026 18:24:47 +0000

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

DEV Community: Amine Affif