In a complex trigger situation:

  • Triggers in base and extension package
  • Complex (many lines of code) trigger logic
  • Many records
  • Extra customer logic (validation rules,...) in target org

our packaged code failes with CPU timeouts. We fixed all usual suspects as

  • generic SObject.get()/put() instead of static field access
  • complex SOQL with Subqueries

without solving the problem. The DeveConsole Execution overview now shows this image and I am unsure what it's telling me. Where is the problem? Is it the long database block?

enter image description here

  • 2
    My understating is that DB activity other than triggers doesn't count towards the CPU limit. I'm not sure how the developer console displays triggers in the timeline view. You might find the Executed Units tab easier to find what is taking the most time. Failing that, it might just be the accumulation of time trying to do to many things in one transaction. – Daniel Ballinger Aug 29 '16 at 10:21
  • 1
    As far as I understood this documentation the validation rules are counted in the CPU time limit. So, looking at your log I'd say that's the biggest problem you currently have as the validation rules are taking as much time as Apex code, which seems weird in my opinion. Maybe they can be optimized a little. Having said that, I must admit that I'm far less experienced compared to you and Daniel, but still wanted to share my thoughts, and maybe learn something as well. – smukov Sep 17 '16 at 20:03
  • 1
    Is there a way to turn off your application and perform the same test? We've often found that while our package might be getting the blame for the CPU timeout, the org might already be running at 90-95% of the CPU limit and adding our package pushes it over the edge. That can at least help rule out your package being the biggest culprit. (Edit: Sorry for the late comment, this just came up in my feed this morning.) – Robert Watson Jun 6 '17 at 17:02

the dev console can help you... you will need to put debug logs on finest for the class you are looking at as well as the running user. Then you will want to change your perspective to show all panels in the console: Debug ==> Perspective Manager ==> Set Default to All ==> save. Setting the panels is a little wonky, you have to double click in the panel you want to set and then you will get an alert asking if you want to set your view to all.

Now run your code and in the developer console go to the panel with Execution Tree/Performance Tree. Sort by Heap or Duration and open the folders which will show you the CPU sucking culprit method(s). Even though CPU is not explicitly called out here you can discern which methods are causing the problem as Execution time and Heap are proximities for your CPU usage. One thing to be mindful of is the debugging will add to your CPU time also. A final thing to help is the Limits class which will aid you in debugging where you are hitting the limits: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_limits.htm#apex_System_Limits_getCpuTime use it like Limits.getLimitCpuTime() to assess how you are taking up time on the cpu.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.