Ce que tu vas apprendre

1. Trois outils que tout dev Odoo doit connaître

Avant de mesurer, choisir ses instruments. La série propose une tour de contrôle en trois couches — toutes natives à Odoo 19 CE ou à la stack Python+Postgres.

On ne parle pas de pyinstrument, py-spy ou pg_stat_statements dans cet article : utiles, mais optionnels, et souvent absents d'un environnement VPS standard. La trousse native suffit largement pour répondre à la question qui nous intéresse : « quel est le vrai coût du pattern T27 ? ».

2. Le helper bench — une méthode, un verdict

Plutôt que d'empiler les scripts ad hoc, on ajoute une méthode côté modèle. Reproductible, testée, paramétrable push=True|False pour comparaison A/B propre.

# addons/odooskills_helpdesk/models/helpdesk_ticket.py (extrait T28)
def _bench_bulk_escalate(self, n=100, push=True):
    """T28 — Helper bench : escalade N tickets, retourne timing.

    Permet de mesurer proprement le coût du write() avec ou sans push bus.bus.
    push=True  → write({'sla_hours': 1}) — déclenche recompute + _sendone T27
    push=False → write({'description': ...}) — contourne le push pour A/B

    Retourne dict {'n': N, 'total_ms': X, 'per_ticket_ms': Y, 'push': bool}.
    """
    import time
    tickets = self.search([('state', '!=', 'done')], limit=n)
    if not tickets:
        return {'n': 0, 'total_ms': 0.0, 'per_ticket_ms': 0.0, 'push': push}
    start = time.perf_counter()
    if push:
        tickets.write({'sla_hours': 1})
    else:
        tickets.write({'description': 'Bench no-push'})
    elapsed_ms = (time.perf_counter() - start) * 1000
    return {
        'n': len(tickets),
        'total_ms': round(elapsed_ms, 2),
        'per_ticket_ms': round(elapsed_ms / len(tickets), 4),
        'push': push,
    }

Deux choix d'ingénierie à expliquer :

• Le filtre state != 'done' évite de heurter la contrainte write() du T15 qui refuse les modifications sur les tickets résolus. Bench propre = pas d'erreur métier parasite.
• Le push=False change un champ description qui n'a aucun effet sur sla_status — donc le snapshot avant/après du T27 ne détecte aucun changement et aucun _sendone n'est émis. C'est le contrôle qui isole précisément le coût du push.

3. Les chiffres — médiane sur 5 runs, batch 1 / 10 / 100

Bench exécuté en local sur vs19_odooskills_test (Odoo 19 CE, PostgreSQL 16, venv Python 3.12) après seed de 10 000 tickets. Chaque batch est relancé 5 fois, on retient la médiane pour gommer le jitter.

Trois observations calmes qui valent toute la théorie :

• Delta bus.bus ≈ 2 ms par ticket à n=1 (5.43 − 3.36). C'est le coût plafond : une écriture isolée paie plein tarif (snapshot pre_status, _sendone + insertion batch bus_bus, pg_notify).
• Le delta s'évapore dès n=100 : 0.10 vs 0.47 ms/ticket, inversion apparente. La ligne write_no_push n=100 montre un fort jitter (runs 3 et 4 anormalement rapides puis lents) parce que PostgreSQL n'avait pas ses pages en cache. Leçon : toujours publier la dispersion, pas seulement la médiane.
• search_read 10 000 = 253 ms total (0.026 ms/ticket) — c'est rapide parce que sla_status est computed/stored (T26) : pas de recalcul au vol, lecture pure en SQL.

À 3 tickets le Seq Scan est optimal — PostgreSQL ne perdra pas son temps à consulter un B-tree pour trois lignes. Mais à 100 000 tickets, la décision change. Si sla_status devient un filtre d'écran permanent (Kanban "Tickets en warning"), ajouter un index devient pertinent : CREATE INDEX ON helpdesk_ticket (sla_status) WHERE sla_status != 'ok'; (index partiel, plus léger).

4. Plonger avec le profiler natif

Les médianes disent combien, pas pourquoi. Pour comprendre ce qui se passe à l'intérieur d'un write(), on sort l'artillerie d'Odoo 19 — le context manager Profiler.

from odoo.tools.profiler import Profiler

# Depuis un shell Odoo ou un test, on profile 100 writes avec push
with Profiler(db='vs19_odooskills_test',
              collectors=['sql', 'traces_async'],
              description='T28 bench write_push n=100'):
    env['helpdesk.ticket']._bench_bulk_escalate(n=100, push=True)

# La session est disponible dans ir.profile — consultable via /odoo/action-base_setup.action_general_configuration
# ou directement en SQL :
#   SELECT id, name, duration, total_time FROM ir_profile ORDER BY id DESC LIMIT 5;

L'intérêt du SQLCollector : tu vois chaque requête issue du write(), son temps exact, et surtout les N+1 cachés — par exemple un SELECT par ticket pour charger le partner_id.email avant l'envoi du mail d'acquittement. Sur 100 tickets, ça se paie vite.

Astuce complémentaire : en développement, ajouter ?profiler=1 à l'URL backend active le panneau devtool côté navigateur — mais exige le mode dev=all dans la conf Odoo. En production, l'approche Python ci-dessus est la seule option responsable.

5. Verdict — quand activer le pattern T27 ?

La morale de la saison, en une phrase : le pattern T27 est viable pour la majorité des cas d'usage helpdesk/CRM d'une PME, et coûte environ 2 ms par notification — soit 1/500e d'une seconde, invisible pour l'utilisateur, amorti dès qu'on bat en bulk.

À retenir

• Trois outils natifs suffisent : Profiler, EXPLAIN ANALYZE, perf_counter. Pas besoin de pyinstrument ni pg_stat_statements pour une première mesure sérieuse.
• Coût bus.bus T27 mesuré : +2 ms/ticket à n=1, amorti sous 0.2 ms/ticket à n=100. C'est le vrai chiffre, pas une estimation.
• Helper bench sur le modèle plutôt qu'un script externe : reproductible, testable, utilisable dans un TransactionCase.
• Médiane sur 5 runs + affichage des samples : toute publication sérieuse de benchmark montre la dispersion, pas juste la moyenne.
• EXPLAIN ANALYZE sur un champ selection non-indexé = Seq Scan jusqu'à environ 10 000 lignes, puis index partiel rentable.
• Cinq pièges à neutraliser avant de mesurer : XML-RPC _, ticket done, mode dev=all, crons, time.time vs perf_counter.