12

Spring 18 included a beta release of deterministic encryption for the SFDC Shield Platform Encryption product. Deterministic encryption imposes fewer issues with your existing code base / metadata than the default probabilistic encryption.

What exactly is the performance penalty should one choose to use deterministic encryption versus no encryption?

11

I encrypted a few PII fields on Contact: enter image description here

and ran this script to insert and then query back 200 Contacts:

delete [select Id from Contact where createddate = TODAY];

/* test cost of encryption */
Contact[] newContacts = new list<Contact>();
for (Integer i = 0; i < 200; i++)
    newContacts.add(new Contact(
                FirstName = 'Fred_'+i,
                LastName = 'Fubar_'+i,
                Email = 'fred'+i+'@bar.com',
                MailingStreet = '123 Easy St #'+i,
                MailingCity = 'FooVille_' + i,
                MailingState = 'CA',
                MailingPostalCode = String.valueOf(i),
                MailingCountry = 'United States',
                Phone = '800-555-'+i));
Long epochBeforeDml = System.currentTimeMillis();
Integer cpuTimeBeforeDml = Limits.getCpuTime();
insert newContacts;
System.debug(LoggingLevel.ERROR,'With deterministic encryption:' + 
             (System.currentTimeMillis() - epochBeforeDml) + 
             ' elapsed milliseconds to insert 200 records.\n' +
               (Limits.getCpuTime() - cpuTimeBeforeDml) + ' cpu ms to insert 200 records.');

Long epochBeforeSoql = System.currentTimeMillis();
Integer cpuTimeBeforeSOQL = Limits.getCpuTime();
Contact[] encryptedContacts = [select Id, FirstName, LastName, Email, MailingStreet, 
                               MailingCity, MailingState, MailingPostalCode, 
                               MailingCountry, Name, Phone
                               FROM Contact where CreatedDate = TODAY];
System.debug(LoggingLevel.ERROR,'With deterministic encryption:' + 
             (System.currentTimeMillis() - epochBeforeSoql) + 
             ' elapsed milliseconds \n' + 
             (Limits.getCpuTime() - cpuTimeBeforeSOQL) + ' cpu ms to query 200 records.');

then, I removed the encryption and ran the same script (adjusting the debug line label to keep things straight).

Results can be see here:

enter image description here

What does this all mean?

First of all, YMMV. The sandbox org where I tested this had (4) workflows and one (1) Process Builder on Contact. There was also an Apex trigger + fflib-style Domain class on Contact.

As such, the absolute values for the elapsed and CPU time to insert or query 200 Contacts are not predictive nor probative.

But what is clear is that there is a performance penalty when you use Platform Encryption. This is not surprising -- think of the computing power used by the bombes and Colossus to decode Enigma -- well, you get the point.

So, how might this affect you?

  1. You could hit CPU limits per transaction if you are close to the limit now. This is especially true for bulk transactions (Data Loader, Bulk API, batchables, ...).
  2. As elapsed times are longer, this means locks are held longer and you may have more contention than you are currently experiencing.
  3. Batch jobs will take longer to run if they reference the encrypted records
  4. Queries will take longer, perhaps in unexpected ways if you are using cross-object or sub-selects.

Of course, the only reason you are using SFDC Shield Platform Encryption is because you have a business requirement for it (like compliance or extremely sensitive data)

Future research

  • Is there an encryption penalty for inserting/updated records where none of the encrypted fields are included in the Sobject to be saved?
  • How much is the encryption penalty if more (or fewer) fields are encrypted.
  • What about penalties for file encryption? Or search index encryption?

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.