09-17-2009 07:11 PM
After having implemented the SalesLogix being affected by low performance. The Saleslogix tends to freeze and often doesn't return to normallity after three minutes or more.
I've previously implemented SalesLogix, but had never faced a scenario with many users simultaneously. On average, there are 45 users online, 8 hours a day. Mostly, they use the accounts, tickets and reports.
- 2.7 GHz, 4 GB RAM, 150 GB HDD
- SQL Server 2000 SP4
- 1.67 GHz.
- 512 MB RAM or 1 GB RAM.
- 10 GB HDD Free, 20 GB Total.
- Not Remote Client
09-18-2009 09:02 AM
Which client is this?
Is this on the intial loading of the Client or whenever switching between tables/records? If initial loading change the default group to a smaller group and check which tabs are open so a large grid is not being opened.
Have you ran SLX Profiler to see where the delay is being created?
You may also want to watch the recored sessions on optimizing indexes etc to improve performance.
Hope that helps
09-20-2009 07:36 PM
- This specs is in all client's PC.
- whenever switching between entities (Account, Contact, Ticket, etc.)
- I already set indexes.
Are client pc's specifications will be the problem? I know that compatibility checklist refers clientes to 512 MB, but it's take in considerations the others appz to use the clients?
07-06-2010 10:57 AM
Somewhat related -- I have a user that says the application freezes almost every time that she goes into Contacts. There are about 12,000 contacts. Says she has to restart several times a day. Anyone else run into this? We are on version 7.2.
07-06-2010 01:26 PM
Groups and grids retrieve data SEVERAL times each from SalesLogix......run the SLX Profiler and start crying......
In general we like to load the entire DB up into RAM on the SQL Server.......
don't forget about multiple SQL Server connections (it is NOT 1 per user), processing power being sucked away by other services, VMWare, CITRIX overhead, etc. on the SLX System box OR user box. 512Mb RAM on the client PC is NOTHING....your user is running IE, EMAIL, WORD, EXCEL, Yahoo Messenger, et al, and then they fire up SalesLogix in 100Mb or so.......OUCH.
Having groups that realistically make sense, and the smaller the better, will improved performance dramatically. Have user's open up very small discrete groups as their defaults! one record, 5 records, Wonderful. ALL or lots of records, Bad. SLX retrieves your Contact group of 12,000 records TWICE and then displays, say 100 of, them on the F8 list view as part of Virtual Server Side Cursors. Individual records of the 12,000 are retrieved One SQL Transaction at a time.....matched to SECCODEID for record level security, matched to SECPROFILE Data blob for Field Level Security.....even if the owner is Everyone......even if every field is Read Write......every time......every sort...... Why this isn't a simple left join to SECCODE via SECRIGHTS is beyond me (that would be fast).....but it definitely is processing each row in your Group retrieval as seperate SQL Transaction (Begin Trans....End Trans)
Did we have user's machines freezing up when they went an retrieved All Contacts, All Accounts, etc. looking up data from 3+ tables including the contact's account's parent's City State Zip? Yes Sir.
Grids are even worse.....they now fire 2+ times every time you go to the tab....grids load/fire on changes in the BINDID, the BINDID in SQL, a change to SQL, change to Connection, grid.Refresh method, and setting the grid's record set to an ADO recordset.....even if any of this is redundant. OOTB grid's that react to CONTACTID or ACCOUNTID (etc.) fire at least twice: once for the change in the BINDID, once for the change to the BINDID in the SQL property of the grid. (and yes, that is redundant and unnecessary!).
Sorting grids are worser still (how's that for a word!).....SLX had gone out and fetched your data, passed it through FLS and Record Level Security for all of the refresh methods invoked that I just mentioned......if the answer is 3 times, that's the answer....one record at a time. The user finally sees the data..... Then the user clicks on a grid caption sort.... it goes through the whole process again on the server....this time with an Order By on the SQL......
5 records, no big whoop. 1,000 records.......death to Smoochie....
We had grid's with 1,000....8,000....14,000 records.....(real world examples: Wal-Mart Store List, Schools in California, Airplanes leased by United Airlines, doctor's in Illinois or working for a big hospital, Employees of GE Lighting).
Quad XENON, lots of RAM, relook at indexing, tighten up Groups, recode Grids.....higher speed disk drives......
07-09-2010 02:03 PM
Thanks RJSamp -- helpful insight. Main user finds that SLX freezes regularly. Need to investigate a bit more.