Build appropriate database maintenance tasks to prune or archive data per best practices and company policy. Review Data Pruning related documentation that outlines the impact and recommendations concerning data pruning within IIQ. It is imperative to system performance over time that data is actively pruned and maintained
Verify the correct Task/Request Server Configuration
The Request Processor and Task Scheduler hosts should be on the same back end server(s). With the introduction of partitioning, the Request Processor is now equivalent to a backend processing server and should be set accordingly in the ServiceDefinition objects.
Do identity refreshes take too long? Consider splitting the identity refresh task. The Identity Refresh tasks could be broken out into separate function-focused sub refreshes to handle specific actions. This type of configuration is a best practice. Separate refresh tasks could be configured to process identity events (triggers), policies and attribute promotion. The identity refresh tasks will undoubtedly run much more quickly when the number of identities are pruned appropriately. However, should performance be an issue going forward, partitioning could be leveraged.
Clean up SysLog Entries. The SysLog typically records exceptions in the system. The exceptions often involve issues with misconfigurations, rules and other custom code. The system should only generate syslog entries when there is truly an issue with the software. Enabling this option will lead to the discovery of errors.
As a rule, there should be minimal logging in production; workflow tracing conflict with that standard. Ensure that this flag is set to false in the Production deployment.
Use partitioning in aggregation and refresh tasks where possible and advantageous
Partitioning the aggregation and identity refresh tasks allows multiple threads and servers to process the incoming data. Only certain applications support partitioning, so this can be implemented for Active Directory and the delimited file applications.
Follow service account best practices. 1. Service accounts should not be directly correlated to human identity cubes 2. Personal accounts should not be utilized as service accounts
Account data should be analyzed and reworked to differentiate between personal and service accounts. Refer to the Compass article for service account best practices.
Logical applications can have performance problems when you configure too many of them. Please make sure you consult SailPoint regarding your logical app requirements.
If you do not have resources on your team with the necessary SailPoint skills sets to take action on the above recommendations you should consider purchasing an Identity CheckUP
If you have already taken action on the above recommendations and are still observing performance issues, you should also consider purchasing an Identity CheckUP
It should be noted that these findings are from real world health checks and some may not apply to your unique IIQ implementation. Also, depending on your SailPoint skill set, some of the recommendations might be too complex to try and resolve yourself. You should consult your implementation partner and/or SailPoint services.
If you believe your team lacks the necessary IdentityIQ skills and experience to take action on the above recommendations, we recommend that you consider an Identity CheckUP
