It is a pretty common complaint that I hear, that CRM 2007 or 7.0 WebUI has performance problems. And since it promises a Web 2.0 experience, your users will expect Amazon.com performance. And, they’re probably moaning at you right now about the “wheel of death”, if you’re reading this blog.
We run SAP CRM 7.0 and we had performance problems on CRM 2007. Now, people see our systems and blink when they see how fast it performs, and our hardware is 3 years old and nearly ready for a refresh.
For the uninitiated, the “wheel of death” is the spinning timer that you get when waiting for a CRM page to load. And the real problem is that if your users aren’t quite bought into having the sales process made more scientific, they might be looking for any excuse not to use CRM, and performance is a good one.
The good news is that if you follow this blog, your CRM system will go like greased lightening and you will be a superhero to your users. The bad news is that there’s lots of things to think about and some of these will take some time and effort to implement.
1) Patch, EhP, Upgrade
I know this might sound like a hassle and slightly predictable but there are some points worth noting here:
a) SAP have consistently improved the performance with each SPS of CRM. Especially if you are on CRM 2007<SPS06 or CRM 7.0<SPS05, do the right thing and patch up to date. Check the BBPCRM component in System –> Status of SAPGui, that is the SPS level.
b) There are some nice new features in CRM 7.0 EhP1 around performance. For example, if you are using quotations or sales orders, it will only run the pricing routines for those elements that have changed. We’ve written custom code to do this in the past and SAP have integrated that into the main product. There is a webcast from fellow mentor Gregor Wolf on EhP1 New CRM Web UI features coming with Innovations 2010“.
c) If you are on CRM 2007 then do the right thing and upgrade to 7.0. It’s a simple technical upgrade and doesn’t generally require a lot of rework as the technology platform is the same. SAP rewrote the UI rendering engine for 7.0 and it is a LOT faster.
2) Hardware & Landscape
CRM WebUI is CPU thread intensive and requires fast hardware. It also makes a lot of small calls – potentially thousands per mouse click – and so both CPU speed and latency are very important.
If your hardware isn’t a recent generation (less than 3 years old) then upgrade your productive system. In technical terms, ensure your CPU has >1000 SAPS per core. The latest systems are pushing 2000 SAPS per core or more.
What’s more, avoid distributed landscapes wherever possible. IT people like to separate database, central instance and application server and CRM 7.0 WebUI hates it, because it increases latency.
3) PC Performance
PC performance also makes a big difference. If you are on slow PCs with an old browser then it will be massively slower. Internet Explorer is the only browser that works with some of the functionality of CRM 7.0 (ActiveX controls etc.) so ensure that you are on the latest version (currently 8.0). Also make sure you have plenty of RAM (1-2Gb on the PC). IT just upgraded my PC and the difference is very noticeable.
Whilst you are there, ensure that you have caching enabled for your browser for your CRM site. On the first load, it will download all the pictures, CSS, etc. and if you don’t have caching enabled to Automatic then it will be downloading the images every time, using network bandwidth and dramatically reducing performance.
CRM 2007 and 7.0 WebUI require HTTP 1.1 to be active – check Note 1162605 – Network performance for CRM (IC) Webclient. Don’t trust your network team on this one – check it out for yourself using a HTTP sniffer like HTTPWatch and check it with your own eyes. Note that the performance may differ depending on where the PC is located as some firewalls and routers force traffic to HTTP 1.0. WebUI performs like a dog on HTTP 1.0.
CRM 7.0 is also pretty network intensive but it does have a setting for slow networks. Click on Personalize then Personalize Layout. Select “Enable fast performance mode with fewer UI features” and “Disable the suggestion of entries for input helps” to improve performance if you are on a slow network link.
Also if at all possible use a caching reverse proxy like Microsoft ISA Server 2010 or squid, for external access to CRM.
5) Database performance
In CRM WebUI, database performance is absolutely crucial. Check transaction ST04 – the hit ratio should be >95%. On our system it is 98.5% with a 6GB cache on Microsoft SQL Server. RAM is cheap, if you don’t have much of it then buy more and give CRM a bigger cache.
We also saw a nice performance by upgrading MSSQL 2007 and following this blog here: SQL Server 2008 Compression on SAP – how to cut your database size from 90Gb to 30Gb. Once 2008 R2 is supported we will upgrade and get the Unicode compression too. Because pages are compressed in cache too, you get better value for money on your database cache.
If you are on Oracle 10g then make sure you patch to the very latest level and follow the holy grail of SAP notes – 830576. If your Oracle DBAs don’t want to apply this then keep hassling them until they do. It can make a dramatic difference to database performance.
6) ABAP buffer performance.
This may sound pretty obvious but ABAP buffer performance in ST02 is really important. Our ABAP program buffer is 1100000 (1.1GB) and this is pretty typical. The default is 300MB. Open up transaction ST02 and see how red the screen is. All those table buffers need to be tuned to give good performance with minimal swaps.
This is important because CRM WebUI is BSP based, which means all the programs can be cached in memory – or alternatively go out to disk!
Do your users complain about waiting for the accounts search for minutes on end? Thought so. Unfortunately the only way around this is to implement TREX for your account searches.
The good news is that if you’re only using TREX for CRM searches and you don’t want to index attachments, then you can install TREX pretty much any . Do however install the latest 7.1 version, which will only run on Windows or Linux 64-bit.
8) ABAP performance
If you’ve done everything else, you may still find that there are specific areas of performance problems. You need to perform a root cause analysis (RCA) of the performance problem but usually it ends up being an ABAP problem in custom code.
For example I recently had an example where performance saving a quotation was awful. It turns out it was making pricing calls to R/3 which were really slow – and run twice – and run, even if nothing had changed. We did three things:
a) Raise a SAP message to get pricing run only once.
b) Improve the performance of the R/3 ABAP code
c) Chance the code so it was only run when products were changed
Either way, you need to do a proper analysis at this point using tools like ST12, ST05 and HTTPwatch.
9) The SAP community connection
There are some neat community resources that are worth looking at
Check the community forums here:
And the BPX CRM area:
CRM can perform as fast – or faster – than Amazon.com, if you put your mind to it and do all of these things. All of these things have been done on our environment and I hope that our Sales Director reads this blog so he realises how much work we went to, to make CRM perform as well as it does today!