Last week, I posted on some of the ways you can try to speed up an Infor CRM SLX system that is suffering from slow performance (here). This week I am continuing with a few more suggestions. But where the previous post was mostly looking at things that can be fixed in the database, this one is mainly looking at adjustments that can be made to the client browser site in IIS.
One adjustment that can be made in IIS that often improves performance is to enable content expiration for the CSS, images, jscript, and Libraries folders. To do this, open the IIS management console, expand the Slxclient folder under the SalesLogix site. Click CSS, then doubleclick HTTP Response Headers in the IIS area. In the Actions pane, click Set Common Headers, the check the box for Expire Web Content in the window that opens. I usually set the expiration for 365 days, but I have seen 30 days suggested in places. I am guessing anything in that range would work, as the goal is the make the content take a long time to expire, but not forever. Now do this same thing for the images, jscript, and Libraries folders (the next three folders in order). Those settings will not take affect until you run IISRESET at an admin command prompt. Also note the content expiration value is overwritten when you deploy the client site, so you will need to do this after every deployment if you need it to help performance.
An additional measure you can take in IIS to help performance is to split the deployed sites into two separate application pools. A single application pool in IIS can only be allocated so much memory. If it gets too close to the limit, it risks locking up. By default, all of the sites under an IIS site use the same application pool. You can manually set one or more of the sites to use a different application pool, which makes it less likely to run up against the memory limit. If it is necessary to use multiple application pool for Infor CRM SLX, it is generally done by placing the Sdata site into its own app pool, as explained here.
Separate from these issues is the very acute slowness often experienced right after a new deployment. This is because the pages that have been deployed don’t actually compile until they are visited for the first time. This slowness will gradually resolve itself as the respective pages are visited, but can really make the web client difficult to use immediately after a deployment. This can be somewhat ameliorated by logging in and visiting some of the more common pages right after the site is deployed, which can at least make sure users can log in and get to those pages without things timing out.
There is also a program you can run to precompile the entire site. It can take ten or more minutes to run, so is best used in situations when users don’t need to log in immediately. Aspnet_compiler.exe needs to be run from the command line so you can include the needed switches, though you could make a shortcut or batch file if you plan on using it regularly. Also, you first need to grab the ID value for the site being compiled from IIS. In IIS, click on the SalesLogix site under the server, then click Advanced Settings in the Actions pane. Make note of the value for ID (should be small integer). Now open a command prompt as administrator, and paste in
C:\Windows\Microsoft.NET\framework\v4.0.30319\aspnet_compiler.exe -m “/LM/W3SVC/X/Root/SlxClient”
Now replace X with the ID value you pulled from IIS. While it chugs along for several minutes, it might not display updates, or it might post a constant stream of warnings. Either is fine. If it actually throws any errors, that would be cause for concern. Once that has completed, run the command again, replacing Slxclient with Sdata. The site should now run at normal speed for users, now that all the pages have been precompiled.
