In every .NET project, you've dealt with performance profiling — SQL query plans, Application Insights…

Reading Between the Lines

Performance troubleshooting in ServiceNow requires a different mindset than .NET — you have no access to the application server, no JVM tuning, no infrastructure scaling. You optimize within the platform's constraints. This tests whether you can be effective with platform-native tools.

The First 5 Checks

• 1. Transaction Log (System Diagnostics → Stats): Shows every HTTP request with response time breakdown — like Application Insights request traces. Filter by slow transactions (>5 seconds). Identifies whether the bottleneck is server processing, database queries, or network. This is your starting point.
• 2. Slow Query Log: ServiceNow logs queries exceeding thresholds. Look for full table scans, missing indexes, or queries returning excessive rows. Like SQL Server's slow query log or EF's Database.Log. Check: System Diagnostics → Slow Queries.
• 3. Business Rule Debug: Enable BR debugging to see which rules fire and their execution time. A single poorly written Before BR can add 3-5 seconds to every form save. Like profiling middleware execution time in ASP.NET.
• 4. Client-side Performance: Browser DevTools (Network tab) shows how many AJAX calls the form makes. Excessive GlideAjax calls or heavy UI Scripts are common culprits. Like checking your React app's network waterfall.
• 5. Semaphore & Worker Threads: Check System Diagnostics → Semaphores. If worker threads are saturated, all transactions queue up. Like thread pool starvation in .NET — your async code helps, but there's a ceiling.

Performance Anti-Patterns

// Anti-Pattern 1: GlideRecord in a loop (N+1 query)
// Like .NET's lazy loading N+1 problem with EF
var incidents = new GlideRecord('incident');
incidents.query();
while (incidents.next()) {
  // BAD: Query inside loop = N+1
  var caller = new GlideRecord('sys_user');
  caller.get(incidents.caller_id);
  gs.info(caller.name); // Separate query per incident!
}

// BETTER: Dot-walk the reference (like navigation properties)
var incidents = new GlideRecord('incident');
incidents.query();
while (incidents.next()) {
  // NOTE: dot-walking still does a per-record lookup (cached per
  // transaction) — better than the explicit inner query above, but
  // for large sets collect the sys_ids and run one batched query
  gs.info(incidents.caller_id.getDisplayValue());
}

// Anti-Pattern 2: No setLimit() on queries
// Like calling .ToList() on a million-row table
var gr = new GlideRecord('sys_audit'); // Millions of rows!
gr.query(); // Returns everything. Instance cries.

// FIX: Always limit
gr.setLimit(100);
gr.orderByDesc('sys_created_on');
gr.query();

Thinking Differently in SaaS

• You optimize queries, not infrastructure: Can't add more RAM or CPU. Reduce GlideRecord queries, use GlideAggregate for counts, index frequently queried fields.
• You optimize scripts, not threads: Can't tune thread pools. Keep Business Rules fast (<200ms), move heavy work to async/scheduled jobs.
• You optimize architecture, not hardware: Can't horizontally scale. Design patterns matter more — batch processing, event-driven architecture, and caching lookup results in script variables (or system properties for rarely-changing values).