Skip to main content

🐢 Find out why a transaction is slow​

This guide goes from "this transaction is slow" to the methods, queries and limits that made it slow. Each step uses a different tab, and links to that tab's page for the details.

Before you start, capture the log with APEX_CODE at FINE or higher. See Recommended Debug Log Levels. Higher debug levels add logging overhead, so all the times are a little longer than in production. Compare times with each other, not with production.

1. See where the time went​

Open the log and start on the Timeline.

  • Look for the widest frames. A wide frame took a long time, and a tall stack above it shows the calls it made.
  • Use the minimap to find the busy part of a long log, then zoom in to it.
  • The color of a frame shows its category, for example Apex, DML or SOQL. The legend in the toolbar shows the self time of each category for the whole log.
  • Hover a frame to see its total and self time.

2. Find the methods that used the time​

Right-click a slow frame and select Show in Call Tree (or select it and press J), or open the Call Tree tab.

  • Total time includes the calls a method made. Self time is the time in the method itself. A method with a high self time is slow itself. A method with a high total time and a low self time calls something slow.
  • Switch to the Bottom-Up view to rank methods by their self time, and expand a method to see which callers called it. See View Modes.
  • Use the Aggregated view to combine the repeated calls of the same method path into one row.

For the whole log in one table, open the Analysis tab. It sorts every method by self time. Group by Caller Namespace to see which package caused the time.

3. Find the slow queries and DML​

Open the Database tab.

  • Sort the SOQL section by time or by row count.
  • A red cross in the Selectivity column marks a query that is not selective. Use the Query Plan column view to see the cost and the leading operation.
  • A query that runs many times shows as a large group. Look for a query inside a loop.
  • Right-click a statement and select Show in Call Tree to see the code that ran it.

4. Check the governor limits​

A transaction can be slow because it is close to a limit, for example CPU time.

5. Check the heap​

Heap size is a governor limit too. If the transaction goes past it, the transaction stops.

  • In the Call Tree, the Memory column view shows heap as Net, Gross and Peak for each call path.
  • A high Gross with a low Net is allocate-then-free churn, not a leak. See Heap: net, gross and peak.

6. Inspect the details​

Select any frame, row or statement to open the Inspector. It shows the timing and governor usage of the selection, the call stack that led to it and a call tree of what ran inside it. For a SOQL query, it also shows optimization tips.

Next steps​