Blog
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);
}
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);
}
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};
var HTTP = { get statusCode() {
// Magic
return status_code;
},
...
get roundTripTime() {
// More magic
return rtt;
}
};
