4 Quick Performance Improvements For Sailpoint IdentityIQ

One thing that can be commonly overlooked in early SailPoint projects is performance tuning. Just like a car, SailPoint will get you where you need to go, but with a little tuning, it can get you there much faster. SailPoint provides a great performance tuning guide with all of the detailed JVM and database tuning options. Here are a few quick ways to improve the performance of IIQ:

  1. Increase dataSourceMaxActive

    This value is stored in the iiq.properties file and controls how many connections IIQ can open to the repository at one time. The default is 50 connections but most databases can handle many more times that. I’ve used values up to 250 without seeing any detrimental side effects. One thing to remember is that if you have multiple IIQ servers, make sure your database can accept the total number of connections from all of the servers.

  2. Designate UI and Task servers

    Most production IIQ environments have multiple servers. It is often preferable to have some servers act as UI servers and others act as task servers. This is accomplished by setting the Task and Request service definitions to include only the names of the task servers. This ensures that users going to the UI servers don’t get a slow response because of back-end tasks like aggregations and refreshes are using system resources. This can help the response times for users. Since these values can be changed without having to restart IIQ, rules can be developed that switch UI to task servers and vice versa. This can be helpful to run overnight and large tasks.

  3.  Setup partitioning
    Partitioning allows IIQ to break up an aggregation or refresh task into smaller subtasks that run independently and can be run at the same time. Identity Refresh partitioning is very easy to setup. In the identity refresh task definition, simply check the Enable Partitioning option. Aggregation Partitioning normally needs to be configured within the Application and then turned on in the aggregation task.

    For JDBC, multiple SQL statements need to be created to select a subset of the users. Make sure that all of your users are captured in your partitioning statements. The following is a basic example of JDBC partitioning statements:

    SELECT * FROM appTable where userid=a* OR userid=b*
    SELECT * FROM appTable where userid=c* OR userid=d*

    For AD partitioning, each partition much be configured under the account.searchDNs tag. The iterateSearchFilter is used to to specify which users are included in this partition. The search filters below would allow the partitions to be broken up by starting letter of the sAMACcountName:

    (&(objectClass=user)(|(sAMAccountName=a*)(sAMAccountName=b*)))

    (&(objectClass=user)(|(sAMAccountName=c*)(sAMAccountName=d*)))

  4.  Increase threads for aggregation and identity refresh

    Along with the partitioning, increasing the number of active threads for partitioned aggregation and refresh tasks allows the tasks to multiplex. These values can be found in the RequestDefinition objects. Increasing the Aggregate Partition and Identity Refresh Partition will allow more concurrent processes to run. It is possible to add too many threads and slow down the overall task. The general recommendation is one thread per core.

    Bonus: Develop with Chome, FireFox or Safari.

    While Internet Explorer is the default browser for most companies, I do all of my development and testing using Chrome, Firefox, or Safari. Nothing against IE, but other browsers seem to run faster and render the screens quicker. This can be helpful during development and testing. The developer tools in Chrome are also helpful in identifying objects when doing custom branding. Always test in IE to make sure everything is good before promoting the code to production.