Performance Issues

Not every problem in an application shows up as an error. A page can load, an API can return 200 OK, and a user can still wait far longer than they should. Performance issues are Middleware's way of surfacing these problems: patterns in your traces that make a request slower than it needs to be, even though nothing failed.

Middleware looks for these patterns automatically in the traces you already send. Backend patterns, such as the same query running over and over, come from APM. Browser patterns, such as a large file blocking the page from rendering, come from RUM. You don't need to turn anything on, and you don't need to write rules.

Each performance issue tells you three things: what pattern was found, where in your application it happened, and how much time it is likely costing. That gives you a specific place to start, instead of a general feeling that "the checkout page is slow".

Where to find performance issues#

Performance issues appear in the same issue list as your other OpsAI issues. Look for the Performance label in the Type column. The Module column shows whether the issue came from APM or RUM, and the tag under each title shows which kind of performance issue it is, for example N+1 DB Query or Uncompressed Asset.

How to read a performance issue#

Every performance issue is written the same way, so you can scan it quickly:

  • Title: Names the operation involved and, where it helps, how many times it repeated or how much time could be saved.
  • What's happening: A plain description of the pattern that Middleware found.
  • Impact: What this pattern costs you, such as added latency, extra load on your database, or slower page loads.
  • Details: The specifics you need to find it in your code, such as the query, the request, or the file involved.
  • Suggested actions: Concrete next steps for fixing the problem.

OpsAI can also investigate a performance issue and propose a fix that you can review. If Auto Investigation is turned on for the source, this happens automatically when a new issue is found. You can also start it yourself with Fix It.

How issues are grouped#

When the same pattern keeps happening in the same place, Middleware groups it into a single issue and keeps count of how often it occurs. You won't get a new issue for every slow request. If the count on an issue keeps climbing, the problem is still there. If it stops, your fix worked.

Before you start#

Performance issues are found by looking at the spans that make up a single request, so they work best when your traces are complete. If your application already sends traces through APM, or your frontend already sends data through RUM, there is nothing more to set up. If you haven't set up either yet, start with APM or RUM.

Issue types#

Database#

IssueWhat it meansFound in
Slow DB QueryA single query takes a long time to return.APM
N+1 DB QueryThe same query runs again and again in a loop, once per item.APM
Consecutive DB QueriesIndependent queries run one after another when they could run together.APM

HTTP and API#

IssueWhat it meansFound in
Consecutive HTTPIndependent slow calls to other services run one after another.APM
Large HTTP PayloadA response is much larger than it needs to be.APM and RUM
N+1 API CallsThe same endpoint is called again and again, once per item.APM and RUM
HTTP/1.1 OverheadRequests wait in a queue because of HTTP/1.1 connection limits.RUM

Frontend#

IssueWhat it meansFound in
Uncompressed AssetA large script or stylesheet is sent without compression.RUM
Large Render Blocking AssetA big file stops the page from showing anything until it loads.RUM

Need assistance or want to learn more about Middleware? Get in touch with us via our Contact Us or join our Slack channel.