Skip to content

Performance Improvements

Compare
Choose a tag to compare
@jamessimone jamessimone released this 29 Mar 16:39
· 14 commits to main since this release
6453b17

Change Overview

Emoji legend: 🟢 new, 🗜internal change, ⚠something to be aware of

  • 🟢 Adds new Logger Parameter CMDT record, Store Heap Size Limit, which relies on the Store Transaction Limits Logger Parameter record to also be true. When set to true, the LogEntry__c.LimitsHeapSizeUsed__c field is set. When set to false, that particular field is not set, and users of Nebula Logger performing bulk data uploads or other bulk data transactions where logging exists at an individual record level may well want to toggle this parameter to false, as it's the single greatest contributor to CPU speed slowdown when logging.
  • 🗜 Centralizes where field truncation is occurring for long text area fields so that less CPU time is spent looping through all of Schema.LogEntryEvent__e prior to publishing platform events
  • 🗜 Caches the System.Limits calls that are static for each transaction
  • 🗜 Simplifies stack trace parsing so that less CPU time is spent suppressing Nebula Logger classes when parsing
  • 🗜 Eliminates duplicated calls to LogEntryEventBuilder.getLogEntryEvent()
  • 🗜 Centralizes how database results are logged within Nebula to enable consistent field truncation for any potential errors
  • 🗜 Logger class now delegates to LogEntryEventBuilder instead of setting fields on Schema.LogEntryEvent__e directly
  • ⚠ Changes how the LogEntry__c.DatabaseResultJson__c stores results: if you were passing a list of results with only one entry in it, that is now recorded as a single entry instead of a single entry in a list
  • ⚠ Changes how Schema.LogEntryEvent__e.TimestampString__c is set - previously, consumers could rewrite a Schema.LogEntryEvent__e.Timestamp__c by calling LogEntryEventBuilder.getLogEntryEvent() and resetting that field. Now, Schema.LogEntryEvent__e.TimestampString__c is only set once when a LogEntryEventBuilder instance is first configured and downstream consumers can call the instance method LogEntryEventBuilder.setTimestamp(Datetime timestamp); if they'd like to override the timestamp later on

All of these changes amount to a substantial performance increase, and performance can be monitored using the new LoggerBenchmarking_Tests class

Benchmarking Stats

Here are some stats associated with this change when logging for 500 records (all times reported in milliseconds):

Branch LoggerBenchmarking_Tests overall LogEntryEventBuilder.getLogEntryEvent() LogEntryEventBuilder() constructor LoggerStackTrace.getCleansedStackTraceLines()
main 16405 1554 4697 1278
main 18178 1690 6309 1360
benchmarking-logger 10377 4511 64 206
benchmarking-logger 10416 4648 67 219

Additionally, LoggerDataStore.EventBus.TruncateStringFields was taking anywhere from ~2130ms to ~2590ms to run in #651 and that method has been eliminated entirely.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.4...v4.13.5