Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
New Member
Posts: 6
Registered: ‎11-04-2014

New SLX Web implementation - very slow to use

[ Edited ]



We implemented SLX Web 8.1, locally hosted, about three weeks ago. 


There are many issues that we're working through still, but the big overarching one, potentially a showstopper, is the performance / speed. It is too slow to work too much of the time.


We've been very careful to ensure that everything is in line with the compatability guide. All client machines are running IE10 on windows 7 (we tried other browsers but the integrations didn't all work). The client machines vary in spec, but they are all at least the minimum required.


The server is being used a the database and web server, with 32 GB RAM with 16 processors.


The network is 1GB.


It is a fairly small implementation - just 32 network users. The database isn't huge, approx 20,000 Accounts and 40,000 Contacts.


The speed seems to be very up and down - if we could get it to stay at the top performance then that'd be acceptable. On some machines it runs at an acceptable speed the majority of the time, and occaisionally it is too slow. On some machines it is occaisionally acceptable and too slow the majority of the time.


When it is slow it is taking ~8-10 secs to load a page on average and sometimes much longer.


The first thing that I'd like to know is what kind of speed we should be expecting? We've come from a desktop based CRM and I know that we'll never get it to those speeds, but I'd like some feedback on what's realistic?


I know that there are many many variables that dictate the speed, but we're running out of ideas and we haven't yet cracked it and I'd dearly like some help from anyone, particularly if you've been in a similar situation and cracked it.


The things we've tried are:


On the system


Getting rid of any filters that aren't used.

Ensuring that all columns which are used as filters, sorts, criteria are indexed.

Changing a lot of the filters to 'lookup' or 'range' instead of 'unique' values.

Get rid of the smartpart tabs under a main entity that aren't used by us.




I've tried monitoring the memory that is used by the client machines and it appears to keep going up when we go on different options and gets slower and slower? Could this really be the case? It looks like it's storing everything in cache, but that there is no limit to this, so eventually it brings the system to its knees.





I've checked the data integrotuy checker to ensure that there are no errors which might be causing timeouts or something, and this is error free.



Please help? What shoudl we be expecting and what can we do about it?


Thanks in advance.

Silver Contributor
Posts: 1,262
Registered: ‎04-08-2009

Re: New SLX Web implementation - very slow to use


This sounds very slow.

The normal speed is 1 - 2 seconds per click.

This speed can be seen after each page was opened one time.

When you first open a page, it is beeing cached an compiled so this takes longer.

If you open a page for the second time, it should go much faster.

This is "resetted" after you stop or restart the application pool or the server.

Also, IE seems to be the slowest browser.

Firefox or Chrome are much faster and can be used, as long as you do not do a mail merge.

The speed of the client computer also inflouences the speed of the web client.

If you have slow machines where the normal browsing takes a lot of time, it also may slow down the web client.


Which version of are you using?


Thanks! Alexander

New Member
Posts: 6
Registered: ‎11-04-2014

Re: New SLX Web implementation - very slow to use

Hi Alexander,


Thank you for the respopnse.  If I can get it to respond in 1-2 seconds then I will be delighetd. At this stage I'll be happy if I can consistently get it to 3-4 seconds. Sometimes it runs at 4-6 seconds per page but it's inconsistent and a lot fo the time it is much slower.


I am aware of the caching on first pass for each page, so everyt ime we redeploy the system we run through all of the pages so that they get compiled prior to letting people loose on it. And these timings that we're getting are not for the first time a page is used.


I'm aware that IE is the slowest broswer but it's been used by sales people that need to ceate proposals so they do need mail merge and it isn't really workable to tell them to use another broswerr until they need to mail merge then use IE.


We're currently testing the individual client machines, but they all meet the spec in the compatibility guide, and in most cases they are fast enough for everything else, including browsing the web with with IE, apart from SLX.


We are using IE10 as we had issues with all of the desktop integration with IE11.


What else would you recommend looking at in order to get a faster speed?




New Member
Posts: 6
Registered: ‎11-04-2014

Slow SLX - 2 further questions



No one seems to really know how to make SLX quicker (certainly no where near the times that Alexander is quoting earlier in this thread) so we have been exploring a few options.


Firstly we need to use the IE browser as this is the only one that works with Mail Merge, and most of our people migth create letters  proposals etc, so we cannot use it. Therefore we've been reviwing all of our IE settings, and the one that has given us the biggest improvement is to do with the IE cache:


Internet options > general > browsing history > settings > temporary internet files > check for newer versions of stored pages.


We had previously been advised that we should set this to 'Every time I visit the webpage' which clearly will have a performance issue, and we've experiemented with changing this to 'Automatically' and we're getting a dramatic improvement. This is great, apart from the fact that we've been peeviously been advised to set it to 'every time I visst the webp[age' because when we were in our testing phase we noticed that the data was not being refreshed, and so if anything was updated it wasn't necessarily being refreshed on other people's pages.


What are other users doing with this? Is there any way of getting it to refresh the data each time but not the rest of the page?


Secondly we've been using the SQL profiler to look through queries that are being firted at the database and optimising our indexes where appropriate. One thing we've noticed is that there apear to be LOADS of queries being fired at the database which are to do with rermote synching. I think that this is for the 'disconnecetd web user' functionality, although we don;t use this. I have set all of the users calendar finctonas to turn this off, but it still seems to be hittng the database every few seconds and I suspect that if I could turn it off I'd get a performance increase in this too. Can anyone advise if I can do this?


Many thanks for any help from any knowledgable SLX guru out there. It could make the difference between us being able to continue using SLX and having to junk it after a huge amount of investment.







Bronze Elite Contributor
Posts: 514
Registered: ‎03-24-2009

Re: Slow SLX - 2 further questions

Have you configured IIS as per the Saleslogix implementation guide on page 46 'Configuring for Performance' ?

Regards, Adam Travers
empath-e Services Limited
Bronze Super Contributor
Posts: 152
Registered: ‎02-01-2011

Re: Slow SLX - 2 further questions

When you say the server is 32GB with 16 procs, are you using this as a single machine or as a VM farm? SQL by design will grow to fill available resources which could potentially choke IIS running on the same machine. You may be able to utilize the resources on the machine more effectively by setting up a VM farm as follows:


SQL - 16gb, 8 proc

Application Server - 8gb, 4 proc ( speed search / job service / memcached)

Web Server - 8gb, 4 proc


This setup "corrals" the high-demand apps so they don't fight for resources. You should have more than enough iron to go around.


Turning off sync can be accomplished as described here:


Also in IIS, be sure your application pools are set to never expire. Remember that the first user to visit a page will experience a slowdown (this is a .NET limitation) so it doesn't hurt to navigate through all pages in the site after deploying/restarting, in order to load the pages into IIS memory/cache.

Andy Freeman
TrellisPoint, LLC