2

Our org is having trouble with our SOQL and CPU Time Limits.

While it is probably true that our own legacy code could be bulkified better, this is a non-trivial, non-short term solution.

Our org has more managed packages then you can shake a stick at. We can see that about 50% of these are consuming our limits.

If we go package by package, we could pick out components which are capable of consumption, but there is no obvious way to identify whether they actually consume, how much they consume, or how frequently they are themselves consumed.

Is there any way we can discover this? Are there any recommended short-term solutions to such issues?

  • 1
    The best way to do this would be analyzing the debug logs. SFDC Dev console provides timings for each operation and trigger for each debug log. – manjit5190 May 15 '19 at 9:42
  • @manjit5190, manually examining hundreds of log sounds painful. I'm more interested in something which can somehow collect and aggregate this information. – Brian Kessler May 15 '19 at 11:34
  • Consider Event Monitoring and corresponding Event Monitoring App. Extra cost though. – cropredy May 16 '19 at 5:58
  • @cropredy what sort of "events" would we look for? Does simply consuming managed packages create trackable events? – Brian Kessler May 16 '19 at 7:54
  • If the managed package is the start of a transaction, then yes – cropredy May 16 '19 at 13:43
2

Managed packages do have their own SOQL limit but not CPU limit: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm.

The only way to debug this is to go through the debug logs. The limits are only within one execution so you don't have to go through all of the logs to find the issues, just the ones that are hitting the limits. You can also see within the log a breakdown of CPU Times and SOQL usage by namespace. It looks like this:

09:19:02.635 (13635310416)|CUMULATIVE_LIMIT_USAGE
09:19:02.635 (13635310416)|LIMIT_USAGE_FOR_NS|(default)|
Number of SOQL queries: 0 out of 100
Number of query rows: 0 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 0 out of 150
Number of DML rows: 0 out of 10000
Maximum CPU time: 499 out of 10000
Maximum heap size: 0 out of 6000000
Number of callouts: 0 out of 100
Number of Email Invocations: 0 out of 10
Number of future calls: 0 out of 50
Number of queueable jobs added to the queue: 0 out of 50
Number of Mobile Apex push calls: 0 out of 10

09:19:02.635 (13635310416)|LIMIT_USAGE_FOR_NS|--NAMESPACE APPEARS HERE--|
Number of SOQL queries: 113 out of 100 ******* CLOSE TO LIMIT
Number of query rows: 752 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 0 out of 150
Number of DML rows: 0 out of 10000
Maximum CPU time: 0 out of 10000
Maximum heap size: 0 out of 6000000
Number of callouts: 0 out of 100
Number of Email Invocations: 0 out of 10
Number of future calls: 0 out of 50
Number of queueable jobs added to the queue: 0 out of 50
Number of Mobile Apex push calls: 0 out of 10
|improve this answer|||||
  • We are not concerned with managed packages that operate in their own limits but with those that operate in our limits (as indicated on the "Installed Packages" page. So far as I understand, only managed packages which have obtained particular certifications get their own limits. We don't care about these. – Brian Kessler May 16 '19 at 7:54

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.