We are running on SBServer2003 network and have CRM3 installed on a seperate
2003 Windows Server with SQL2000 Server installed. The CRM server is Xeon
Dual 2.8Ghz, with 2GB ram, Raid 10 SCSI HDD and only have CRM running.
I don't know where to start to find out why it is slow... any suggestion?
If upgrading the hardware would help, we will do it, but I doubt this will
help as we checked the CPU usage, Ram usage, and network usage, they all have
plenty of rooms to move.
Please anyone any suggestion?
Sindy
Is CRM slow all the time, or just on the first access? I notice the same
behavior (and I guess everybody does), but once the initial page is loaded,
CRM is very fast on our environment, and our system configuration is worse
than yours. We had some issues with an internal proxy server. Some of the
data transfered to/from CRM went through the proxy, so responses were deadly
slow. After adding the CRM server name and ip address to the list of
addresses that should bypass the proxy, we "only" face the slow performance
occasionally, but not in general.
Just a thought.
--
Michael
----------------------------------------------------------
"SW" <S...@discussions.microsoft.com> schrieb im Newsbeitrag
news:67E292A0-AA9C-482A...@microsoft.com...
I have just posted somthing which may be of interest.
Post name "CRM speed enhancement!!"
Have a look, hope it helps you.
Regards,
Nathan Warner
If its client side (using 100% CPU for several seconds between clicks), I
know the answer.
Its a bug in the software somewhere. The problem is non-existant on dual CPU
or hyper-threaded CPU mahcines. Likewise, changing networking conditions to
e.g. connecting from home with a single CPU machine, changes the timing so
that the problem disappears.
If this is part of your problem, I suggest that you open a support case with
Microsoft.
- Could be the initial JITting of web pages by ASP.NET
o Should be fine if you let the CRM system tray process run in the
background.
- Could be a known issue with email tagging + very large folders as
well
o Receiving new emails “freezes” the client for a few seconds)
o The workaround is to disable aggressive email tagging (see “perform
additional checks…” option under 'system settings --> Outlook
synchronization' )
--
Manisha Powar
Program Manager,CRM
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2005 Microsoft Corporation. All rights
reserved.
I dont think you're right because:
1) Its hardly JIT. The 100% CPU is used on the client machines using IE
only. And it does not happen on the first clicks, but instead on successive
clicks. Problem disappears on hyper-threaded CPUs, or changed network latency.
2) No tray. No client software. Only IE. Nothing else. Which mutes all of
the remaining posts.
It looks to me like a client side deadlock timing problem, causing the local
CPU to go to 100% for 5-8 seconds (who knows, maybe its try to poll from the
server in a tight loop while being blocked for the 5-8 seconds) .
--Michael
We are experiencing similar problems.
If I click between the Accounts and Contacts Lists on the main menu
sometimes it takes around 1-2 seconds to change will other times takes 15-20
seconds.
During the longer refresh times my Client CPU maxes out at 100%.
I don't really see why it should take so much longer sometimes, it is really
degrading the user experience.
Did you reach any conclusions with your problem?
Best regards,
Mike
Guys, I solved our problem for almost all users/computers:
In IIS, browse to the file '<crm virtual
dir>/_common/scripts/Stage.js', show properties, goto 'HTTP Headers'.
Check the 'Enable content expiration' checkbox, and select the 'Expire
immediately' option (now this file (5kb) will be retrieved for each
request, instead of caching it locally)
Now clear the temporary internet files of your local browser, and open
MSCRM again.
This solved our problem, for 2 MSCRM 3.0 installations for almost all
users (only one user still faces the same problem, but he will
reinstall his computer...:-)
Please let me know wat your experience is with this 'workaround'...
Thanks so far!
Regards,
Evert Jan
We have had this trouble all along and presumed it was just down to the much
talked about JIT caching.
If anyone from Microsoft is listening I'd recommend this workaround is
documented somewhere, it is such a simple change that makes the application
work so much better.
Cheers
Mike
Thanks for your help!!!! :>)
- Tracey