September 17th, 2007

TFS 2008: Controlling the number of threads used in uploading and downloading files

Buck Hodges
Director of Engineering

The TFS version control client object model normally uses up to eight threads from the thread pool to upload or download files.  This same mechanism is also used in pending adds: Files are opened to determine whether they are binary or text, so batches are sent to the server while other batches are being examined on disk.  It also uses eight threads.

Some customers have encountered a problem where a firewall will consider these multiple simultaneous connections to the server to be suspicious activity and block them (e.g., interpret them as a DOS attack).  In TFS 2005 there was no way to control this.

In TFS 2008 (beta 2 and newer), we added a way to control how many threads are used.  You can control how many threads are used by changing the .config file (tf.exe.config, devenv.exe.config, or your own app’s .config, depending on what you are running) and set VersionControl.MaxBackgroundThreads to the number you desire from 0 to 64 (defaults to 8).

For example, the following will restrict it to two threads.

   <appSettings>
      <add key=”VersionControl.MaxBackgroundThreads” value=”2″ />
   </appSettings>

If you set the maximum number of background threads to zero, the request is made on the calling thread rather than a thread from the thread pool.

Some customers have reported that they have solved the problem by having the TFS client bypass the network proxy for local (intranet) addresses.  You can do this by changing the settings in IE to bypass the network proxy for local addresses.  Alternatively, you can change this just for TFS by setting the following registry value.  You can set the following in either HKLM (global for the computer) or HKCU (for a particular user on the computer).  Change 9.0 to 8.0 if you are using TFS 2005 rather than TFS 2008.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\RequestSettings]

“BypassProxyOnLocal”=”true”

Author

Buck Hodges
Director of Engineering

Director of Engineering, Azure DevOps

0 comments