I encrypted a few PII fields on Contact:
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:
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?
- 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, ...).
- As elapsed times are longer, this means locks are held longer and you may have more contention than you are currently experiencing.
- Batch jobs will take longer to run if they reference the encrypted records
- 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?