For the next few posts, I am going to talk about some of things you can do to help a slow Infor CRM SLX system. Some of the things I mention will be ones I have mentioned before that I want to update and include in this context. I also point out that many of these solutions involve making changes directly in the CRM database. These steps should be done by a SQL administrator, or qualified SQL technician. As with any time you are working with live data, it is recommended to take a backup of the SQL database before making any changes, just in case.
Infor CRM SLX has considerable need for RAM memory and processor speed. This applies to the application server, web server, and database server. It also benefits from having extra disk space on the drive holding the database. It is difficult to quantify, but I consistently see better performance on generously-provisioned systems. Infor has traditionally shied away from providing specific spec requirements, partially because the minimum to get the get the software to run is much less then the minimum needed for acceptable performance. Also, the specs needed for good performance can vary widely depending on how the system is used, and how many users are on the system simultaneously. I posted on specs several years ago (here), and the numbers I would recommend have crept up only slightly since then. If you have a heavily-used system with a good number of users I suppose I would recommend at least 4 cores on the processor, and at least 16 GB RAM, with some use cases potentially needing to double either or both of those for good performance.
One of the more resource-intensive items in Infor CRM SLX is the Groups that users can create in each section. Dynamic Groups work off of queries, and can slow things down for a user as they run each time they load a section. Ad Hoc groups are basically just a user-maintained list, but the table containing all Ad Hoc Group items can grow quite large and impact database performance if no Groups are ever deleted. While reminding users to get rid of Groups they no longer need might sufficient in some cases, Infor has suggested procedures for getting rid of excess Groups. This is done at the database level, so would be a task for a database admin. This procedure tags all Dynamic Groups eligible for deletion with TBD, and gives users a chance to edit the TBD out of the Group name for any Groups wish to keep, then runs a query to delete any groups users did not choose to save. This procedure does a similar thing for Ad Hoc Groups. Either procedure could also modified to delete Groups based on other criteria.
Another possible source of slowness is SpeedSearch. If SpeedSearch is running properly, this should not be an issue. However, if something is off with the SpeedSearch indexes, it can cause the INDEXUPDATES table to grow to to a very large size. I first suggest using the Administrator LAN program to verify the SpeedSearch indexes are updating successfully, as explained in this post. You can also check the size of the INDEXUPDATES table to see if it has grown so big as to cause issues. Run the query
select count(*) from sysdba.INDEXUPDATES
to see how many records are in that table. If it is over a few thousand records, it is a good idea to clear out the table. Run
truncate sysdba.INDEXUPDATES
to get rid of all records in the table, then delete the SpeedSearch index files and run a full index of all entities. SpeedStearch should now be working (assuming you did the first part correctly), and you are starting with a clean INDEXUPDATES table.
Next post, I will continue with ways to combat slow Infor CRM SLX performance, starting with measures that can be taken in IIS.
