3

I found out recently that our org is using ~85% of its data allocation. The number one offender for usage (13%) has no one looking at it. The number two offender for usage (7%) has no one looking at it. The number six offender...well, you get the idea. Just eyeballing it, I estimate we can lower our data consumption by at least 35%. I imagine that will have some impact on performance.

Does anyone already know if there is a well established effect on performance, and if so, what is it? Or stated as the converse, is there a known performance degradation as usage approaches the limit?

If the answer is not already known, I would like to test this hypothesis as we go about the process of eliminating so much data. Are there benchmarks I can run to evaluate performance before and after the purge? I can think of the following measurable indicators that may be affected:

  1. Query Plan results
  2. Visualforce Page load times
  3. Synchronous Apex execution time
    • Triggers, controllers, etc.
  4. Asynchronous Apex execution time
    • Batches, Queueables, @future methods
  5. Flow Engine
    • Workflows, Flows, Process Builder

My main methodology when profiling code looks like the following:

Long start = Datetime.now().getTime();

// optional loop to increase granularity
// operation to benchmark

Long elapsedMs = Datetime.now().getTime() - start;

I'm not sure how I could adapt that to profile performance on batches and triggers. And I'm really not sure if it's possible to get a good picture of how flow performance is affected.

Do I stand to gain anything besides getting our instance more safely below the limit?

4

Salesforce doesn't experience any performance penalty as you near your org's capacity. Each large object has no effect on the performance of small objects. Your org will run just as efficiently at 105% capacity as it will at 5% capacity.

There are two cases where you'll notice performance degradation. The first is that if a single parent object has many children, it can take longer to display or query in some cases. The second case is that non-indexed queries involving a large object will take longer to run (including reports and dashboards). If neither of these apply, there's no performance penalty for having this data laying around.

If nobody is using those objects, there shouldn't be any real performance problems, nor will you specifically get better performance by cleaning up the data. That said, the more you go over 100%, the greater the possibility that the system will stop allowing insert and update DML operations.

You should definitely clean up before you get too far past 100% capacity, because those large objects could prevent DML even on your small objects.

|improve this answer|||||
  • Thankfully I caught it before we went over 100%. Still, under 50% is much more margin for error! – Adrian Larson Aug 9 '16 at 20:14

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.