Caching Expensive GlideRecord Queries…

intermediateTested on Xanadu

The Caching Expensive GlideRecord Queries pattern addresses performance bottlenecks caused by repeatedly executing the same costly database operations. When multiple users or processes frequently query the same relatively static data, each execution hits the database unnecessarily, creating scalability issues and poor response times.

This pattern implements strategic caching at different scopes using ServiceNow's built-in caching mechanisms. GlideSystemCache provides instance-wide caching for data that changes infrequently, session-scoped variables cache data for individual user sessions, and Script Include static properties offer transaction-scoped caching. The pattern automatically handles cache invalidation and provides fallback mechanisms when cached data is unavailable.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Use This When

Use this pattern when you have expensive queries that execute frequently with the same parameters, such as configuration lookups, reference data retrieval, or complex aggregate calculations. It's particularly valuable for data that changes infrequently but is accessed often, like organizational hierarchies, system properties, or catalog categories.

Avoid When

Avoid this pattern for rapidly changing transactional data where cache invalidation becomes complex, or when the query results are highly user-specific and unlikely to be reused. Don't implement caching for simple, fast queries where the caching overhead exceeds the performance benefit, or when real-time data accuracy is more critical than performance.

Implementation

Server-side

var CachedQueryUtils = Class.create();
CachedQueryUtils.prototype = {
    initialize: function() {
        this.CACHE_PREFIX = 'cached_query_';
        this.DEFAULT_TTL = 300; // 5 minutes in seconds
    },

    // Instance-wide caching using GlideSystemCache
    getCachedSystemProperty: function(propertyName) {
        var cacheKey = this.CACHE_PREFIX + 'sysprop_' + propertyName;
        var cache = new GlideSystemCache();
        
        var cachedValue = cache.get(cacheKey);
        if (cachedValue !== null) {
            gs.info('Cache hit for system property: ' + propertyName);
            return cachedValue;
        }
        
        // Cache miss - query database
        var gr = new GlideRecord('sys_properties');
        gr.addQuery('name', propertyName);
        gr.query();
        
        var value = '';
        if (gr.next()) {
            value = gr.getValue('value');
        }
        
        // Cache the result with TTL
        cache.put(cacheKey, value, this.DEFAULT_TTL);
        gs.info('Cached system property: ' + propertyName);
        return value;
    },

    // Session-scoped caching for user-specific data
    getUserDepartmentInfo: function(userId) {
        var sessionKey = 'user_dept_' + userId;
        
        // Check session cache first
        if (gs.getSession().getProperty(sessionKey)) {
            var cached = JSON.parse(gs.getSession().getProperty(sessionKey));
            // Check if cache is still valid (5 minutes)
            if (new GlideDateTime().getNumericValue() - cached.timestamp < 300000) {
                gs.info('Session cache hit for user department: ' + userId);
                return cached.data;
            }
        }
        
        // Query user and department information
        var userGr = new GlideRecord('sys_user');
        userGr.addQuery('sys_id', userId);
        userGr.query();
        
        var deptInfo = {};
        if (userGr.next() && userGr.department) {
            var deptGr = new GlideRecord('cmn_department');
            if (deptGr.get(userGr.department)) {
                deptInfo = {
                    id: deptGr.sys_id.toString(),
                    name: deptGr.name.toString(),
                    manager: deptGr.dept_head.toString()
                };
            }
        }
        
        // Cache in session with timestamp
        var cacheData = {
            data: deptInfo,
            timestamp: new GlideDateTime().getNumericValue()
        };
        gs.getSession().putProperty(sessionKey, JSON.stringify(cacheData));
        
        return deptInfo;
    },

    // Static property caching for transaction-scoped data
    getConfigurationItems: function(category) {
        // Use static property on the class for transaction-scope caching
        if (!CachedQueryUtils.configCache) {
            CachedQueryUtils.configCache = {};
        }
        
        if (CachedQueryUtils.configCache[category]) {
            gs.info('Static cache hit for configuration category: ' + category);
            return CachedQueryUtils.configCache[category];
        }
        
        // Expensive query with joins and calculations
        var gr = new GlideRecord('cmdb_ci');
        gr.addQuery('category', category);
        gr.addQuery('install_status', 'IN', '1,6'); // Installed or In Use
        gr.addJoinQuery('cmdb_rel_ci', 'sys_id', 'parent')
            .addCondition('type.name', 'Runs on::Runs');
        gr.query();
        
        var items = [];
        while (gr.next()) {
            items.push({
                sys_id: gr.sys_id.toString(),
                name: gr.name.toString(),
                state: gr.install_status.getDisplayValue()
            });
        }
        
        // Cache results for this transaction
        CachedQueryUtils.configCache[category] = items;
        gs.info('Cached ' + items.length + ' configuration items for category: ' + category);
        
        return items;
    },

    // Cache invalidation method
    invalidateCache: function(cacheType, key) {
        if (cacheType === 'system') {
            var cache = new GlideSystemCache();
            cache.invalidate(this.CACHE_PREFIX + key);
        } else if (cacheType === 'session') {
            gs.getSession().putProperty(key, null);
        } else if (cacheType === 'static') {
            if (CachedQueryUtils.configCache) {
                delete CachedQueryUtils.configCache[key];
            }
        }
        gs.info('Invalidated cache: ' + cacheType + ' - ' + key);
    },

    type: 'CachedQueryUtils'
};

The code demonstrates three caching strategies with different scopes and use cases. GlideSystemCache provides instance-wide caching with TTL for system-level data, session properties cache user-specific data with timestamp validation, and static class properties enable transaction-scoped caching for expensive queries. Each method includes cache hit detection, fallback database queries, and proper cache invalidation mechanisms.

Alternatives

Database Views and Indexes

Creates optimized database structures for frequently accessed data combinations, providing consistent performance without cache complexity, but requires database administrator involvement and may not reduce query frequency.

Scheduled Job Pre-computation

Uses scheduled jobs to pre-calculate and store expensive query results in custom tables, ensuring predictable performance and data freshness, but requires additional storage and may not suit real-time scenarios.

Client-side Caching with Local Storage

Leverages browser storage to cache query results on the client side, reducing server load and improving perceived performance, but introduces data staleness risks and requires careful invalidation logic across browser sessions.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue