Scott Nicol
posted by Scott Nicol on November 29, 2016
Find me on: Scott Nicol on LinkedIn

CRM performance on a virtual environment.pngI came across an interesting situation the other day while on customer site – a puzzling situation which raised lots of questions, where the answer went against everything I thought was correct about CRM performance on a virtual environment. Here’s what I found out.

The way virtual hosting platforms (VMWare, HyperV etc.) handle hardware is already known to be a ‘challenging’ area to fully understand for IT personnel. Specifically for the customer I was working with, they use a VERY seriously powered virtual host which runs production and development servers. The issue they were reporting with CRM was that performance was just generally poor navigating from one area to another in the web client, which of course isn’t that helpful for us when trying to diagnose the issue!

So we scratched our heads and looked at the spec of the servers – but the machines were assigned more than enough resources. In fact, the web server alone had 8 processors on a development/test system with only 1 or 2 concurrent users. “How can this be possible?” we said…

We checked all the things you would normally check when performance is mentioned – number of processors, amount of RAM, remaining disk space, disk activity, IIS caching & precompiling, database activity and much more… but everything was already configured optimally. At this point, we consulted with an infrastructure expert who mentioned that the particular virtual platform being used (VMWare) handles assigned processors in an ‘interesting’ way. It actually waits for all assigned processors to become available before beginning any task!

To explain the impact of this, because the virtual host was hosting many Virtual Machines (VMs), resources (specifically, processors) were constantly being redistributed between servers, which is normal for a virtual platform to do. The only problem was that because so many processors were assigned to the CRM server, the machine had to wait for all 8 cores to become available before being able to perform any requests, thus resulting in a consistent latency problem.

In the end, the issue was resolved by REDUCING the number of processors assigned from 8 to 2.

So what can we learn from this?

Well, we know that the way virtual hosts handle hardware can be tricky and given what we have seen in this case, perhaps it is better to split the different services of CRM out onto a number of different virtual servers, rather than having one big virtual server running all CRM processes. In the case of physical servers though, the above information will be irrelevant as there is no virtual platform interfering with hardware allocation and distribution.

Have any questions about the performance of your CRM system? Contact us today on 01959 560 410 to see what we can do to save you time.


  • Leave a Reply