CPU timeout in production org due to strange waiting lags cannot be reproduced in slow DE org

Our managed package runs into CPU timeouts in a customer production which we tried to reproduce in our DE packaging org.

We added some of the custom workflows, formulas and rollups but where unable to provoke a CPU timeout in the DE org.

When comparing the Dev Console timeline from failing Customer org

enter image description here

and our DE org

enter image description here

I can only draw the following conclusion. Executing code is slower in the DE org (as production orgs are faster) but the root cause for the timeout is the long waiting periods between the actual execution.

Can someone explain those lags and how I can influence them?

Note: The repeated blocks on the timeline don’t show any kind of loop! Its a huge amount of records which is handled in 200 record chunks by triggers.

Answer

Here are reasons why do you see waiting lags OR gaps in your graph:

  • Log levels not specific enough:

    If your debug log level filters aren’t set to the appropriate levels, the Developer Console will automatically filter out finer-level events, making it sometimes appear as if there were gaps in execution. This is remedied by setting your log levels appropriately.

  • Log file truncation:

There is a maximum log limit of 2MB per log file. When the limit is hit, detailed log lines are removed, which can result in what looks like gaps in the log. The log lines can be removed from any location, not just the start of the debug log. Note that when lines are removed due to the log file limit, they are removed in ENTRY / EXIT pairs. For example, the lines for a SYSTEM_METHOD_ENTRY and SYSTEM_METHOD_EXIT might both get removed, in order to keep the log view consistent. An example of this sort of gap might look like:

08:37:13.187 (1187280618)|CONSTRUCTOR_EXIT|[984]|01p|(ApexPages.StandardSetController)
08:37:13.620 (1620485725)|METHOD_EXIT|[5181]|01p|CartDetailViewController.searchCartLineItems()

Whereas the actual complete log without truncation would look like:

08:37:13.187 (1187280618)|CONSTRUCTOR_EXIT|[984]|01p|(ApexPages.StandardSetController)
08:37:13.187 (1187311551)|SYSTEM_METHOD_ENTRY|[993]|ApexPages.StandardSetController.cancel()
08:37:13.620 (1620440718)|SYSTEM_METHOD_EXIT|[993]|ApexPages.StandardSetController.cancel()
08:37:13.620 (1620485725)|METHOD_EXIT|[5181]|01p|CartDetailViewController.searchCartLineItems()

Apex component initialization cost in Visualforce pages: Using Apex properties or methods in Visualforce pages can sometimes hide the time taken for the component initialization code. For example, if you had a Visualforce component that called getParamValue() in the Apex controller via the debug log would not catch the initialization cost of .

  • Static Apex methods:

Calling static Apex methods will reference the static method in a different class, which might result in a cache miss and thus an extra compilation cost that will not be tracked in the debug log. For example, if you defined the following:

public class ClassA {
    public void call() {
        ClassB.staticCall();
    }
}

public class ClassB {
    public static void staticCall() {}
}

and created an instance of ClassA and called call():

ClassA obj = new ClassA();
obj.call();

the call to the static ClassB method staticCall() might reflect a gap in the debug logs.

  • Salesforce Apex processing issues:

In some scenarios, things like extra compilation cost (perhaps due to converting a large amount of Apex code into bytecode) or a garbage collection sweep can result in a gap in the debug log.

All of these issues can cause gaps in the debug log, and are not indicative of any performance problems by themselves. Keep these in mind when reviewing your debug logs.

Authoritative reference: https://developer.salesforce.com/page/Troubleshooting_Apex_Performance_Problems

Here is how you can resolve Maximum CPU time issue:

  • Set the log level finest and get the complete graph of of execution
  • Identify which code bock is taking maximum time
  • optimize that code block
  • repeat this process till your code works

Generally this type of issue come due to heavy data in customer org. You will have think about optimizing your code or process those bulk records in asynchronous way

Attribution
Source : Link , Question Author : Robert Sösemann , Answer Author : AtulRajguru9

Leave a Comment