Trigger Optimization 101: Accessing Metrics

When accessing metrics in ExtraHop Application Inspection triggers, save cycles by using variables right. Here's how.

optimizing ExtraHop

I hope you all had a great Boxing Day and are ready to dive in because it's time for another Trigger Optimization 101, where we discuss small changes that yield big improvements in trigger performance.

If you're just joining us, make sure to check out the previous post, Trigger Optimization 101: Exit vs. Return, where we covered the best way to end trigger execution. Please leave any comments or feedback below, as well as any requests for future topics to cover, and I'll get back to you personally.

As always, you can follow along in your own environment, or use a personal sandbox in the online demo. Once you're ready, let's dive into today's topic: accessing ExtraHop metrics in triggers.

Your References Are Out of Control

Watch the following video (3:18) which demonstrates the performance cost of referencing any collected metrics.

 

The ExtraHop platform extracts thousands of metrics across dozens of protocols, which are all exposed via the Triggers API. If those who aren't familiar with the API, a quick overview. Metrics are stored as properties of various classes. Generally, these classes are tied to specific protocols (eg HTTP or Kerberos) in addition to some ExtraHop-specific classes (eg Device and Flow). These properties store metrics or information about the specific transaction. Examples include HTTP.roundTripTime, which exposes the network latency (RTT) for the web transaction, and HTTP.headers, which exposes all of the headers associated with the request or response.

There are several situations in which you might access the same metric several times. A common reason: checking logic. Look at the following code:

// Page Not Found
if (HTTP.statusCode === 404) {
    debug('Your failures are your own, old man!');
}
// Server-side error
else if (HTTP.statusCode >= 500) {
    debug('Theyre inside you building a monument to compromise!');
}
// Woo
else if (HTTP.statusCode === 200) {
    debug('Success');
}
// Anything else
else {
    debug(HTTP.statusCode);
}

In the above code, we're checking for multiple possible status codes, and taking prescriptive actions. However, if you watched the video, you'll notice that we can actually simplify the above trigger and see a significant performance improvement by declaring a HTTP.statusCode as a variable. Compare the following trigger performance to the above:

var status_code = HTTP.statusCode;

// Page Not Found
if (status_code === 404) {
    debug('Your failures are your own, old man!');
}
// Server-side error
else if (status_code >= 500) {
    debug('Theyre inside you building a monument to compromise!');
}
// Woo
else if (status_code === 200) {
    debug('Success');
}
// Anything else
else {
    debug(status_code);
}

From our comparison, we get this week's rule: if you are using a metric more than once, you should be creating a variable. Take some time and look through your triggers. Are there places you can optimize through variable creation?

Taking our new rule deeper, what causes the performance impact when referencing metrics multiple times? The answer lies in how the data is stored behind the ExtraHop classes. Many of you might be familiar with access JavaScript object properties and expect ExtraHop classes to be populated similarly:

var HTTP = { 'statusCode' : 200,
                  ...
             'roundTripTime': 25};

Behind the scenes, metrics are actually accessed using object getters. Getters are functions within an object which return a requested value, but are not simple object properties. Instead, think of them as computed properties. In a vast oversimplification, our HTTP object looks closer to the following that the previous snippet:

var HTTP = { get statusCode() {
                // Magic
                return status_code;
             },
             ...
             get roundTripTime() {
                 // More magic
                return rtt;
             }
};

Those functions are executed every time the metrics are accessed, including all the associated overhead. So we again arrive at our original conclusion: if you are using a metric more than once, you should be creating a variable. Hope you find that useful and can continue to improve your triggers! Leave any questions or comments below, and I'll be back again next week for another Trigger Optimizations 101!

Start your ExtraHop demo

Subscribe to our Newsletter

Get the latest from ExtraHop delivered straight to your inbox.