function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
steve_andersensteve_andersen 

Problems with governor limits in complex Apex

I am building a fairly complex set of apex triggers and classes that does the following:
  • Automatically create a custom object (household) whenever a Contact is created
  • Keep that custom object in sync with the Contact as it changes
  • Automatically create Contact roles on Opp insert when you flag the Contact in the data
  • Create contact roles automatically for other Contacts connected to the primary contact's household
  • Roll up Opportunity amounts to the Contact that is primary contact role, and household members
We've built out a bunch of triggers, classes and tests. We've done lots of bulk testing, and think we understand how batches work, and how that affects the various governor limits. We can't test all scenarios that we might see in the data--there are limits to how large the test batches can be which makes it impossible to predict how large batches will behave.

When doing rollups like we're doing, we end up getting lots of data. Each opp we insert has one primary contact role, which could have 10 opportunities, and those opp ammounts need to be rolled up to that contact and the couple other contacts in it's household.

When we run across contacts that are primary on a lot of opps, we're running into script execution limits and heap size limits. These limits seem way too low if we're hitting them with 200 contacts that have a total of 300 opporunities we want to roll up. We've done some refactoring to avoid loops inside of loops to keep execution down.

I have found through trial and error that I can reduce the number of errors by turning the batch size down to 100 or 50. This is much slower, but stays below the governor limits. But even at a batch size of 50 opps being inserted, I'm still going over my heap size in some cases.

I've also run into one problem where my code for adding Contact Roles on Opp insert doesn't add contact roles to all opps at a large batch size, but does at a smaller batch size. The alarming thing is that no Apex errors are thrown during the import process, leading me to believe my code is executing correctly. If udates were failing, or a list was too large, or too many DML or SOQL statements, I would expect an error. We're stumped on this one right now.

I know complex code situations like mine surely can't be diagnosed over these boards, so I'm writing this more to express concern about the utility of Apex for more complex coding like we're trying to do. Dealing with batches, navigating the landscape of these low governor limits, not being able to write tests for real-world situations, seemingly not getting errors when I expect them are all concerning to me. We're really excited about Apex, but the learning curve and now the reality that we may not be able to do much of what we want to do becuase of low governor limits is getting us down right now.

Any thoughts would be appreciated!

Steve

kpetersonkpeterson
Hi Steve,

You've run into the exact same situation that we are in now.  We are very excited about what Apex can do for us but we're already hitting certain limits.  It was great when we got our first triggers implemented and deployed but now that we're adding more triggers we're quickly finding out that apex in one trigger is firing other triggers and our governor counts are quickly adding up to the limits.  Normal use usually involves updating one object which fires off triggers on a couple of other objects and is not a problem.  I'm afraid though what will happen when someone tries to do an import or a large api call.  We've tested for bulk but our bulk sizes must be very small to stay within the limits.
TehNrdTehNrd
Here is something I have done to cope with triggers executing triggers and running up governing limits.

I have created is a flowcontrol class that indicates when and if a trigger should be "exectuted". For example if I have 3 Account triggers that execute on update and I have a trigger on a related opp that updates this account, I must ask myself when this opp updates the Account do all 3 triggers really need to fire? If they answer is no we can't prevent the triggers from executing but we can prevent the logic from executing.

Here is a piece of my flow control class
Code:
global class flowControl {
  
  //---------------------------Application Automation Trigger Control--------------------------
  public static boolean runApplicationAutomation = true;
  
  //Return the run trigger boolean   
  public static boolean runApplicationAutomation(){
   return runApplicationAutomation;
  }
  
  //Set the run Trigger boolean
  public static void setRunApplicationAutomation(boolean value){
   if(value == true){
    runApplicationAutomation = true;
   }else{
    runApplicationAutomation = false; 
   }
  }
}

 We can set a boolean variable that indicates whether a triggers logic should be execute. Then at the very begining of trigger you can insert somethign like this:

Code:
boolean runTrigger = flowControl.runApplicationAutomation();
   if(runTrigger == true){
Do all the trigger logic
}

 


steve_andersensteve_andersen
Thanks for that tip. I did something to manage execution as well, but it has more to do with turning trigger functionality on and off.

I created a Settings object with a checkbox called Process_Rollups__c. I check to see if the checkbox is checked, and run the code if it is, don't run it if it isn't. This has been very helpful with large updates and deletes where I don't need the triggers to fire--the throughput goes up significantly if all the Apex processing isn't happening:


Code:
Setting__c thisSetting = [select Process_Rollups__c from Setting__c limit 1];
 
boolean ProcessRollups = thisSetting.Process_Rollups__c;
 
//skip all this if don't want to rollup
if (ProcessRollups) {
.
.
.
}

 
Steve
TehNrdTehNrd
Nice, some type of execution control is required with the ability for triggers to "cascade". Perhaps salesforce.com could provide some best practices in Apex reference guide.

I'm curious what type of performance hit salesforce.com servers have taken since the release of Apex. Looks like we will have to keep using these flow control methods until the limits are raise, which I assume will happen some day.


Message Edited by TehNrd on 12-13-2007 11:47 AM
Ron WildRon Wild
Boy I hope they do raise the limits!  I'm spending more time trying to work around them than I am developing actual workflow logic.

Some best practices and tricks from SFDC would also be helpful.


El_DevEl_Dev
Steve,
 
The Sales Execs want a daily count of Accounts and Account Types to be displayed automatically on their home page.  There are of course 1,000's of Accounts so this needs to be developed on Apex.  Question can you help me with a WebMethod and the scripting?
 
El
steve_andersensteve_andersen
that sounds like a dashboard to me...