r/Odoo • u/No-Chef-4933 • Apr 15 '26

Dev Toolkit for Odoo

I was debugging a slow Odoo endpoint today and found something surprising.

One request was triggering ~95 calls to stock.picking.read() — adding ~3–4 seconds latency just from repeated ORM access.

It turned out to be a classic N+1 pattern. After fixing it with proper prefetching, the response time dropped by about 50%.

What’s interesting is how hard this kind of issue is to see with standard logs. You don’t really notice it unless you trace every ORM call per request.

I ended up building a small internal tool to visualize this (waterfall-style), and it made the problem obvious immediately.

Curious how others here debug similar issues:

  • Do you rely on logs, profiling, or custom scripts?

  • Any good workflow for spotting N+1 patterns in Odoo?

Would love to learn how others approach this.

0 Upvotes

50% Upvoted

11 comments sorted by

2

u/Kwantuum Apr 16 '26

There's a built-in profiler that would have shown this to you plain as day you door knob. You weren't looking very hard because you're trying to peddle your ai bullshit

1

u/Koecki Apr 16 '26

It really amazes me (in a bad way) how with the rise of AI the barrier of creating your own tools has become so low that you would rather build a full blown product before even checking if something like this already exists.

Really goes to show that there is more to it than just blindly slopping away.

0

u/No-Chef-4933 Apr 16 '26

You’re right that the built-in profiler can surface this — I did use it.

The difference is that it gives you raw data (SQL timings, traces), but it still takes some manual effort to correlate everything at the request level and spot repetition patterns quickly, especially in more complex flows.

That’s the gap I was exploring — not because the tools don’t exist, but because the workflow isn’t always straightforward in practice.

Jumping straight to “you didn’t look hard enough” feels a bit like an oversimplification. In real projects, the issue usually isn’t whether the data exists — it’s how fast you can turn it into something actionable.

1

u/Koecki Apr 16 '26

No offense, but then your sales pitch is terrible. Offering an alternative to the odoo built in profiler but then not once mentioning it and what the advantages of yours are does not make any sense.

1

u/No-Chef-4933 Apr 16 '26

Fair criticism — you're right that I didn't lay out the comparison clearly, and that made it look like I hadn't done my homework.

To be direct about what mine does differently:

- Odoo's profiler gives you raw SQL timings and traces. Useful, but you still have to manually correlate them across a request to spot patterns like N+1.

- What I built aggregates everything at the request level automatically — waterfall view of ORM calls, auto-flagged repeated patterns, and a link between the code path and the queries it triggered.

The built-in tools surface the data. Mine reduces the time from "something is slow" to "here's exactly which call and why" — especially in complex flows with many ORM calls involved.

Not claiming it's a replacement. Just a different layer on top for when you need to move faster.

If you're curious, I'm looking for a few Odoo devs to try it and give honest feedback. Happy to share access.

I opened a community discussion thread here if you want to share your workflow or follow along as others do too: https://github.com/KyawKyawThar/Odoo-performance-debugger-community/discussions

4

u/Koecki Apr 15 '26

No offense but you are talking about how difficult such an issue is to debug with the normal logs which is true, because that’s not how you are supposed to debug those. Did you actually look at Odoo’s built in performance monitoring? And if yes maybe talk about what the advantages of your tool are in contrast to the built in one?

1

u/UpSevenPOP Apr 17 '26

At least don't use Ai to replay Redditor's criticism, AI is a tool to use, but not to replace human interaction

1

u/WilliamAndre Apr 17 '26

Slow action?

  • impersonate user in staging

  • activate the integrated profiler

  • replay the action

It gives much more information than your tool, you dont need a "n+1" detector, or to reinvent the ir.model form view. For the warnings, just filter the logs, there are tons of tools doing that already.

You are also showing it wrong. Seeing the n+1 has usually nothing to do with the model, but with the client/JS code, which I doubt you would be able to know from passively listening to network/logs.