Benchmarking BeanShell in IIQ: Keep Performance Smooth

Imagine IdentityIQ as a factory. Each BeanShell script is like a conveyor belt—when one belt lags, everything downstream slows too. Now, would you run a factory without ever checking which belt is causing the holdup? Exactly.

Why Measure BeanShell Performance?

In SailPoint IIQ, custom scripts often feel harmless at first. Maybe it’s a Rule fetching accounts, or something small added to an aggregation. But if it runs hundreds of times? A 100 ms delay per identity becomes minutes of slowness. Profiling avoids that snowball effect.

The Stopwatch Approach: Still Valid

Let’s say you want to measure how long it takes to fetch accounts from a certain application. Quick and dirty:

long start = System.currentTimeMillis();

// simulate some account fetching
Thread.sleep(100);

long duration = System.currentTimeMillis() - start;
log.debug("Fetching accounts took: " + duration + " ms");

  

It’s like timing how long it takes your coffee machine to brew—fast, useful, and better than guessing.

Level Up with the Meter API

SailPoint’s Meter class lets you track performance like a pro. It’s already built into IdentityIQ and visible in the Debug → Call Timings page. Think of it as adding a speed tracker on every step of your logic.

Let’s say you want to check how long it takes to load accounts (Links) from the “Workday” application for every user:

import sailpoint.api.Meter;
import sailpoint.object.Identity;
import sailpoint.object.Link;
import sailpoint.object.QueryOptions;
import sailpoint.object.Filter;

String targetAppName = "Workday";
Meter.reset(); // Clear previous metrics

Iterator<Identity> users = context.search(Identity.class, new QueryOptions());
while (users.hasNext()) {
    Identity user = users.next();

    Meter.enterByName("Fetch-Workday-Links");

    List<Link> links = user.getLinks();
    for (Link link : links) {
        if (link.getApplicationName().equals(targetAppName)) {
            log.debug("User: " + user.getName() + " | Account: " + link.getNativeIdentity());
        }
    }

    Meter.exitByName("Fetch-Workday-Links");
}

Meter.getThreadMeters().getMeters().forEach(m -> m.print());

  

You just added a radar gun to your factory line. For every identity, this script checks how long it takes to find their Workday accounts—and logs it. Want to test Okta or AzureAD instead? Change the targetAppName.

Debug → Call Timings: Your New Favorite Page

Once that script runs, flip to the UI:

• Hits → how many users were processed
• Avg time → average load time per identity
• Max time → your worst-case scenario
• Errors → caught exceptions (if any)

This dashboard helps answer: Where exactly is my IIQ slowing down?

Common Pain Points Meter Can Expose

• Using context.search() inside tight loops? Move it outside or batch it.
• Re-processing the same data for each identity? Cache it.
• Calling external systems line by line? Aggregate instead.

You can’t optimize what you can’t measure. Meter tells you where the pain lives.

Final Thoughts

Don’t wait until users complain. Add small Meter blocks while developing your Rules or Workflows. Think of them like blood pressure monitors—quietly tracking what’s normal, and warning you when something’s off.

Already used Meter in a creative way—or found a performance killer thanks to it? Let me know. I’d love to hear how you’re keeping your IIQ fast and furious.