ProTip : Trigger Optimization in 18 Characters



Quick Trigger Optimization Tip

tl:dr; Defensive programming FTW!

During a training session a few days ago, I wrote a trigger to look at certain files being accessed on one CIFS server.

The code was simple:

if ( CIFS.resource.match(/stuff-we-care-about/) ) {
    // we care about this file, build an application
    Application("CIFS Files of Interest").commit();

We assigned the trigger and let it “cook” for a few minutes.

We had the metrics we were after. We were trying to answer the question “Hey, who is accessing that?! We decommissioned that months ago.”

Resource Consumption

Triggers aren’t “free” in a computational sense. They take a measurable amount of time to execute. Some triggers are more efficient than others.

To measure trigger performance, look at the Performance tab in the trigger editor.

Here’s what we saw:

Let’s unpack that.

In 30 seconds,

  • the trigger ran 30,000 times (“Executes: 29.99K”)

  • the trigger consumed 1.43 billion CPU cycles (“Total: 1.43G cycles”)

Rule of thumb: G cycles or T cycles is a lot.

The Problem

Looking at the Debug tab in the trigger editor we noticed some errors. Specifically, when trying to do a .match when CIFS.resource was null.

The Fix

We modified the first line in the trigger to read:

if ( CIFS.resource && CIFS.resource.match(/stuff-we-care-about/) ) {

We just added 18 characters: CIFS.resource &&

The logic there says “if we have a CIFS.resource and the CIFS.resource contains the string ‘stuff-we-care-about’”.

It’s a simple way of handling the case when CIFS.resource is null.

And, for reasons we will read about in a minute, handling this case is a Good Thing.

The Result

Again from the Performance tab in the trigger editor:

  • approximately the same number of executes (26.88K vs. 29.99K)

  • HUGE decrease in CPU cycles consumed (76,970,000 vs. 1,430,000,000)

Pretty good return on investment for 1 minute of work and 18 characters.

The “Why”

Raising exceptions (errors) is transactionally expensive in the ExtraHop trigger engine. So, it’s best to practice defensive programming and handle errors before they happen.


I would add that this is a MUST do activity for all triggers. Looking at the Settings -> System Health there is a panel that shows the Exceptions by Trigger. This is a great way to look at those Triggers with exceptions and use the technique described above to add some bullet proofing to your script.

I recently came to a company that has an existing EH in place. No one had looked at the Exceptions in awhile. It just worked. By using this technique I was able to bring the exceptions down from 80K down to the single digits.

My advice - Do an audit on your system to verify all is good.