Udostępnij za pośrednictwem

Slow Team Foundation Project Creation or operation? Check your NIC settings

  • Artykuł

We had a minor firestorm today as we saw major performance degredation trying to create new Team Projects on pretty speedy server configuration. We all panicked for a while until a few folks remembered we'd seen something like it before and checked the NIC settings...

Basically when the NIC settings on one of the machines doesn't match the NIC settings on the other, things go badly wrong. So, if one NIC is set to be 100 MBPs full duplex, and another is set to Auto Detect, you end up with one of the NICs queuing up packets while it is hunting for the correct speed. If you have a NIC which invokes the autodetection process frequently, you end up with delayed packets and sometimes timeouts and failovers.

This is not the first time we've lost significant time debugging this issue - and it's a pretty common problem. Dennis Habib found some knowledge base articles that could be useful if you think you might be experiencing similar slowdowns:

I searched around for a while and found an article describing some issues with the ‘auto-sense/auto-detect’ mode on some network adapters, specifically:

https://support.microsoft.com/kb/174812/

There’s a good article about how auto-negotiation works (and some warnings that some cards/drivers don’t do it correctly resulting in poor performance) at:

https://www.cites.uiuc.edu/network/autosense.html

Most of the articles I read suggest manually setting this item may be necessary depending on the switches/hubs/NICs in the network environment.

We've been hit by this problem several times internally, so I have to assume that people outside of Microsoft might be impacted by this issue too. It's going to be most obvious when you're trying to create a Team Project - especially when creating the Sharepoint Portal because this is the most network intensive part of the project creation process. However, it will impact any team foundation operations with significant network traffic - could be publishing work items in Excel (especially pre-Beta 3) or Source Control operations etc.

Bill Essary, our architect, has been doing a lot of work on measuring the limits of our system - which was how we discovered the issue today, and ended up using tools to measure the network bandwidth on each computer (AT, DT, Client) to see if they were roughly as expected. I can't remember the details of the conversation exactly, but we're using a gigabit network and were seeing something like 3 MBps performance :-)

If you're looking for tools to do something similar Bill did a quick hunt here on CNet. We haven't tested any of these tools, so I can't vouch for them in any way...

Comments

  • Anonymous
    October 29, 2005
    Back in July we lost a day (a very long day) on the July CTP schedule because Justin and I were trying to figure out why source control operations were pitifully slow. It was this same NIC setting problem -- the image used to set up the test machines had the wrong setting.

    http://blogs.msdn.com/buckh/archive/2005/07/27/444027.aspx

    And then we had to fix the upgraded dogfood server also that week when it had the performance same problem. It was the first thing we checked. :-)