The N+1 Queries Problem is a perennial database performance issue. It affects many ORM’s and custom SQL code, and Django’s ORM is not immune either. In this post, we’ll examine what the N+1 Queries Problem looks like in Django, some tools for fixing it, and most importantly some tools for detecting it. Naturally, Scout is one of those tools, with its built-in N+1 Insights tool.

When visiting a new website, it is quite normal to get carried away by the bells and whistles of the fancy UI and UX and not be able to appreciate all the lower level, back-end code that runs tirelessly to ensure a smooth and fast website experience. This is because your front-end HTML code has a visually rich browser page interface as a platform to showcase its output. Whereas your back-end, server-side code usually only has a console at its disposal.

All programming languages provide efficient data structures that allow you to logically or mathematically organize and model your data. Most of us are familiar with simpler data structures like lists (or arrays) and dictionaries (or associative arrays), but these basic array-based data structures act more as generic solutions to your programming needs and aren’t really optimized for performance on custom implementations. There’s much more than programming languages bring to the table.

Web frameworks are powerful tools. They abstract the common aspects of building web sites and APIs and allow us to build richer, more stable applications with less effort. A broad range of web frameworks is available to us in Python. Some are proven favorites with large ecosystems and communities. Others excel in niche use cases or for specific kinds of development. Still, others are up-and-comers with compelling new reasons to be considered.

Most modern web applications are heavily reliant on persisting data with relational databases, and so it’s no surprise that a large part of application performance monitoring relates to keeping an eye on database performance to ensure that our SQL queries are as efficient as possible. With this in mind, Scout features a Database Addon module, and in this video we are going to take a closer look at what it has to offer.

Errors are undesirable for users and you should do everything in your control to keep users away from them. However, they are of utmost importance for developers. They allow developers to understand the inaccuracies and vulnerabilities in their code by alerting them when their code breaks. They also provide relevant information about what went wrong, where, and what can be done to make amends.

Our instrumentation uses built-in extension mechanisms where possible, such as Django’s database instrumentation. But often libraries have no such mechanisms, so we resort to wrapping third party libraries’ functions with our own decorators. For example, we instrument jinja2 ’s Template.render() function with a decorator to measure template rendering time. We value the correctness of our instrumentation a lot so that we do not affect our users’ applications.

In this video, we are going to take a look at what memory bloat is, and how you can use Scout to eliminate it from your applications. Memory related performance issues have the potential to bring your entire application down, and yet, most APMs completely ignore this fact and fail to provide any useful way of monitoring memory usage at all.

Memory leaks can happen in any language, including PHP. These memory leaks may happen in small increments that take time to accumulate, or in larger jumps that manifest quickly. Either way, if your app has a memory leak, sooner or later it will cause problems. The source of and solution to PHP memory leaks aren’t always obvious, so you may need to try a few strategies before you eliminate the problem.

Ruby may be over 25 years old, but it remains popular in the software community for its focus on programmer happiness. Building software with Ruby often involves leveraging one or more popular frameworks for the purpose of increasing productivity by relying on existing solutions to common problems. Ruby frameworks generally fall into two categories: web-facing frameworks and background job frameworks.