Much of Lighthouse’s performance can be attributed to how well the application server is running and how well your repository database is running. Various application servers and databases will have their own specific set of performance tuning techniques. I’ll leave it up to the manufacturers of those apps to provide their performance tuning best practices.
Some of the larger bullet items in Lighthouse to look for:
- JVM settings for Lighthouse, the more JVM Lighthouse can get the better. The absolute optimal amount of JVM to provide to Lighthouse is dependant on how many users are in your environment and how much you can afford to give to Lighthouse. All I can say is the more the better.
- Continuing with the JVM settings, setting the min and max amount of JVM available to Lighthouse is a common practice. By doing this you eliminate any wasted processor time re-allocating more memory as Lighthouse operates.
- For reconciliation, setting listcache.size in waveset.properties to 0 has shown to be a vast improvement on the time it takes reconcile to operate. This is something that should be done as a temporary configuration during your initial user load of Lighthouse as it’s effectively disabling the list cache in Lighthouse.
- Another tip when reconciling is to remove any attributes in the schema map that are unused in Lighthouse. The fewer the attributes, the less reconcile will go and fetch.
- Any form of tracing, be it workflow, XPRESS, gateway, or even method tracing affects performance. When not interested in capturing debug information it’s ideal to turn off any tracing.
No comments:
Post a Comment