Performance architecture

IdentityIQ performance is overwhelmingly a story about three things: the database, how heavy tasks are structured, and the JVM. Get those right and the platform scales comfortably to hundreds of thousands of identities; get them wrong and even a modest deployment crawls. The golden rule throughout is measure before you tune, blind changes usually make things worse.

The heaviest operations are almost always:

• Identity refresh, recomputing cubes, roles and policy across the whole population.
• Aggregation, especially full aggregation of large targets.
• Certification generation, which can produce enormous numbers of items.

These are batch jobs, and their cost scales with population size, so they are the first place to look when the system feels slow.

The database is the usual first bottleneck. The key measures:

• Ensure the vendor-recommended indexes exist, and add indexes for any extended attributes you filter or search on heavily.
• Right-size the connection pool so task servers are not starved or thrashing.
• Keep statistics current and watch for slow queries; the ORM will happily generate expensive queries if the schema is not indexed for your access patterns.

Heavy tasks should be partitioned so their work is split across threads and task servers instead of running as one long single-threaded job. Combine this with delta aggregation so you read only changed data, and schedule the heaviest jobs off-peak so they do not collide with interactive use.

Size the heap for the object volume, too small and you get constant garbage collection and out-of-memory failures; too large and GC pauses grow. Monitor GC behaviour rather than guessing. Separate UI nodes from task nodes so a memory-hungry batch job cannot degrade the interactive experience.

Poorly written rules are a common, self-inflicted performance problem. A rule that loads a large object graph, or issues a database query, inside a loop over every identity will dominate refresh time. Fetch narrowly, avoid per-identity queries where a bulk approach exists, and profile custom rules under realistic volume.

• Baseline: capture how long key tasks take and where time is spent.
• Change one lever (index, partitioning, heap) at a time.
• Re-measure against the baseline.
• Keep what helps, revert what does not.

• Tuning by folklore instead of measurement.
• Full aggregation and unpartitioned refresh at scale.
• Custom rules that query the database per identity.