Apex Code Development You need to sign in to do that
Don't have an account?
steve_andersen Problems with governor limits in complex Apex
I am building a fairly complex set of apex triggers and classes that does the following:
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
- 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
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
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.
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
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:
boolean runTrigger = flowControl.runApplicationAutomation(); if(runTrigger == true){
Do all the trigger logic
}
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:
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) { . . . }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
Some best practices and tricks from SFDC would also be helpful.