Designing for Performance Part 6

[Chris Pearson]

In the last of our designing for performance series, let's discuss a final common pitfall that lead to poor performance. These come straight from a SN webinar delivered by their Account Escalation Engineering (AEE) team.

This one you could describe as writing code 'defensively'. This means to not just assume that the database will be in good health with reference to the data on tables you are expecting to be in place. Don't trust anyone! Code defensively. When you call a method which requires parameters, check to make sure the calling code gave you values for those parms. Also, when querying a table for a value from a field which is used in a second query, make sure you actually got a record back from the first query. If you don't, the second query will ignore that line of code and may return back way more records than you were expecting. Here's an example:

var userId = gs.getUserID(); //get the currently logged in user's sys_id
var accounts = new GlideRecord('u_aps_accounts'); //a custom table
accounts.get('u_user', userId); //get the accounts associated to the logged in user
var arr = [];
var members = new GlideRecord('u_m2m_aps_entitlem_aps_accounts'); //another custom table
members.addQuery('u_active', 'true');
members.addQuery('u_aps_accounts.sys_id', accounts.sys_id);
members.query();
while (members.next()){
	arr.push(members.getValue('u_aps_entitlements'));
}

The code assumes each use has an entry in a custom account table. But, when no account is present, the variable 'accounts' is undefined and the filter is dropped, returning all active rows from the second query. This turned out to be 5.3 million records in this scenario. This crushed the instances memory usage, causing severe performance issues until a simple IF statement was added to check for a valid 'accounts.sys_id' prior to running the second query.