blog.sentry.io
Performance Issues: Insights meet action | Sentry
Excerpt
After talking with developers about their workflow, we uncovered that the current application monitoring tools out there are not built for them. Those same developers wanted the workflow that Sentry provides for errors, but for performance. For example, when you go to Sentry to understand what’s behind an error, the stack trace and details on the Issues page generally give you enough detail to understand what you need to do to fix the problem. … ### N+1 Queries: The most critical database problem to catch early N+1 queries are one of the most common database problems that can easily go unseen (until the query overwhelms your database and in some cases takes down your application). For developers using the Django Python framework, you are probably all too familiar with this issue. The Django framework provides a helpful Object-relational mapper (ORM), which allows you to write your queries in Python and then turn them into efficient SQL. Most of the time the ORM executes perfectly, but sometimes it does not - resulting in SQL queries running in a loop. These queries include a single, initial query (the +1), and each row in the results from that query spawns another query (the N). These often happen when you have a parent-child relationship. You select all of the parent objects you want and then, when looping through them, another query is generated for each child. We actually wrote a blog post about an N+1 query problem of our own that occured in our backend – the query executed 15 times and added an additional 380ms. We were able to catch it early (before it got out of hand) by using Sentry Performance. But for most, this problem can be hard to detect at first, as your website could be performing fine. But as the number of parent objects grows, the number of queries increases too…until your database collapses. That’s why detecting these types of problems early is critical to maintaining stability.
Related Pain Points
N+1 query problem causes excessive database calls
8Developers frequently fetch all list items then make separate database calls for each item's related data, resulting in exponential query multiplication (e.g., 21 queries instead of 2 for 20 blog posts with author data). This becomes catastrophic in production with large datasets.
Monitoring tools not designed for developer-centric performance workflows
6Current application monitoring tools lack developer-friendly workflows for performance issues comparable to error debugging. Developers want the same level of detail and actionability for performance problems as they get for error tracking, but this is not available.