Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

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.

share|improve this answer
    
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 '10 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 '10 at 20:07
up vote 0 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.