5 000 requêtes SQL pour afficher un panier

5 000 requêtes SQL. Pour afficher un panier de 30 articles sur un site e-commerce.

Je te raconte.

J'arrive tout juste dans la boîte, et je fais le premier truc que n'importe quel pro de la perf devrait faire : inspecter le panier. On me dit : "Tu verras, c'est pas fou-fou". J'ouvre blackfire, je cherche une trace avec 30 articles.

Je déglutis.

Plus de 5 000 requêtes SQL. Pour un seul affichage de panier.

Pas une erreur de mesure. Pas un batch caché. Juste l'ORM qui fait son boulot. Mal, mais c'est la faute du marteau si on l'utilise comme scie ?

Le problème, et c'est un classique que je croise régulièrement : personne dans l'équipe ne se souciait réellement de ce qui se passait backstage. On code des objets, on appelle des méthodes, ça a l'air propre côté applicatif. Sauf que derrière, le moteur enchaîne les jointures une par une, article par article, référence par référence.

30 articles × des dizaines de relations × zéro optimisation des requêtes = un festival du n'imp.

Le truc, c'est que ça marchait. Avec 5 articles dans le panier, personne ne voyait rien. Mais à chaque fois qu'une vraie personne remplit un vrai panier, la base transpire.

Mon conseil ce jour-là, le même que je donne depuis des années : ouvre le capot de ton ORM. Regarde le SQL qu'il génère. Lis la doc.

Un ORM, c'est un accélérateur au démarrage, pas une excuse pour ignorer ce qui se passe en base.

80 à 90% des problèmes de performance back-end que je rencontre sont liés à la façon dont on requête la base de données. Mauvaises jointures, indexation absente, pools de connexions mal configurés, cache inexistant. Et très souvent, un ORM qu'on a laissé faire ses courses tout seul sans vérifier le ticket de caisse.

Tu scaleras pour 10 000 quand t'auras scalé pour 1.

Si ton panier e-commerce génère 5 000 requêtes pour 30 articles, t'as pas un problème de scalabilité. T'as un problème de curiosité.