A 44-second export: measure before you look

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