0

I have a quad processor vmware instance running Windows 2003 and 1gb ethernet. I'm comparing serving the exact same heavy .NET 2.0 content from the local hard drive versus serving it from a UNC drive.

If I use WCAT to load it down, I see about a 40% reduction in transactions/sec while serving from the UNC. Processor time barely moves from 45% and the NIC sits around 40% either way. I don't see any significant memory loading either way. Context Switches/Transaction, though, more than doubles when serving from the UNC. Pathlengths more than double as well, but I believe that's just an expression of the effect of context switching.

All told, it looks like the bottleneck is processor switching while waiting on content from the UNC share. Is my experience about the norm? Is there some mitigation I might try?

I twiddled HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\MaxCmds a little bit per http://technet.microsoft.com/en-us/library/dd296694(WS.10).aspx, but to no obvious effect. I kind of doubt my problem is lack of connections, but rather just the act of switching from thread to thread while waiting on data.

2 Answers 2

0

We found that VMWare VM's degrade the network substantially, not in throughput, but latency, something like 40%. Our specific case was Active Directory traffic. However perhaps using physical is not something you can do.

2
  • Some of our production use will be on VM, but not all. I'll probably have to dig up a physical box somewhere and test there. Thanks.
    – codepoke
    Feb 26, 2010 at 17:56
  • Which virtual ethernet card do you use? maybe you can gain some performance with another driver. for example the new vmxnet3 card which is available with VMware vSphere.
    – grub
    Jun 13, 2010 at 20:07
0

About a year later, I still remember this one. The solution was to ramp back from 4 processors to 2 on the VM instance. It's counter-intuitive, but adding processors to a VM instance increases contentions on the VM host. The host will only allocate processor time when there's a certain number of slices available or some such, and when 4 virtual processors are all looking for time on the host processors they end up blocking each other more than processing. Cutting back to a single processor led to hard bottlenecks, but 2 processors was the sweet spot on our hardware.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .