TFS 代理效率测试

• 下载 TFS Proxy 测试批处理源文件 - 35 KB

引言

一家公司里的开发团队结构可能需要设立分布式办公室。当然，并非所有公司都能使用宽带互联网通道来处理远程版本控制系统。因此，问题就出现了，我们如何才能提高版本控制系统的速度？微软公司为那些使用 Team Foundation Server 作为版本控制系统的用户提供了 Team Foundation Server Proxy 应用程序。

接下来的问题是 TFS Proxy 的性能和优势。在本文中，我想让您理解以下几点：

• 如果我们使用 TFS Proxy，哪些操作会执行得更快，快多少？
• 哪些操作根本不使用 TFS Proxy？
• 本地计算机、TFS 和 TFS Proxy 服务器之间的流量是如何共享的？
• 互联网通道速率对操作执行时间有什么影响？
• 各种 TFS Proxy 设置对操作执行时间有什么影响？

背景

在我公司的客户要求使用他们的 TFS 服务器时，我计划了这项调查。问题是我们公司的互联网通道很窄，而且拓宽它非常昂贵。

在获得将所有项目迁移到客户服务器的提议后，我们开始思考如何消除互联网速度问题。我们找到了一些关于微软公司、其远程办公室以及如何使用其 TFS Proxy 的文章。所以，我们也考虑使用 TFS Proxy，但我们主要的问题是 TFS Proxy 在慢速互联网通道上是否有效。

我们的互联网通道速度为 128/64 Kbps（下载/上传），据我们估计，本地 TFS Proxy 应该非常有效。此外，我们决定测试带有更宽互联网通道的 TFS Proxy，以测试整体系统性能随互联网通道速率的变化。

硬件和软件规格

我测试了最新版本的 Visual Studio 和 TFS 命令行工具（9.0.21022.8）。

为了模拟不同速率的互联网通道，我使用了 SoftPerfect Bandwidth Manager v2.5 build 230。

本地计算机配置

• CPU：AMD Athlon^(TM) 64 X2 双核处理器 4000+
• RAM：2 GB 内存
• HDD：Maxtor STM3250310AS，250GB，SATA-II
• Windows XP SP3

TFS Proxy 配置

• CPU：AMD Athlon^(TM) 64 处理器 3000+
• RAM：2 GB 内存
• HDD：Maxtor 6Y160P0，160GB，UDMA-133
• Windows Server 2008

TFS Server 配置

• CPU：AMD Sempron^(TM) 3500+
• RAM：2 GB 内存
• HDD：Western Digital WDC3200AAKS-00SBA0 320GB，SATA
• Windows Server 2003 SP2

条件

我们在以下互联网通道速率（上传/下载）下进行了测试：

• 64Kbps/128Kbps
• 128Kbps/256Kbps
• 256Kbps/512Kbps
• 512Kbps/1024Kbps
• 1Mbps/2Mbps
• 2Mbps/4Mbps

此互联网通道速率列表从我们公司目前拥有的速率开始。我使用了最标准的速率来涵盖大多数情况。入站通道的速度不重要，它可以是出站速率的八分之一到四分之一。

我们测试了以下 TFS 命令：

• Get
• Check-Out (签出)
• Undo Check-Out (撤销签出)
• Check-In (签入)
• 历史
• 差异

在我公司，这些命令的使用频率很高，所以我决定首先测试它们。

我们模拟了以下 TFS Proxy 状态：

• TFS Proxy 已启用，缓存 0%
• TFS Proxy 已禁用
• TFS Proxy 已启用，缓存 90%
• TFS Proxy 已启用，缓存 100%

第一种选择（Proxy 已启用，缓存 0%）不太可能，但我还是决定测试它，以便与第二种选择进行比较。

第二种选择（Proxy 已禁用）揭示了 TFS Proxy 优势方面最重要的信息。此外，我选择此选项作为与所有其他缓存情况进行比较的基础。

第三种选择（Proxy 已启用，缓存 90%）代表了 TFS Proxy 在大多数常规使用情况下的状态。

第四种选择（Proxy 已启用，缓存 100%）是 TFS Proxy 缓存可能达到的状态，可以通过常规的代理服务器缓存更新来实现（请参阅此处）。此状态应该比前一种稍微快一些，并且可以在任何软件团队中实现。

为了进行 TFS Proxy 测试，我们创建了一个存储库并上传了测试数据。测试数据代表了一个真实的项目（请参阅下表了解详情）。

项目大小，MB	10.2
缓存大小（整个项目），MB	3.1
项目中的总文件数	1732
项目中的总文件夹数	145
总 `*.cs` 文件数	569
`*.cs` 文件大小，MB	1.47

测试方法

为了测试所有 TFS 命令、TFS Proxy 状态和互联网通道速率，我使用了以下方案。我为每个 TFS 命令实现了一个命令文件（`.cmd`）（见下例）。此文件将允许设置 TFS Proxy 地址、执行 TFS 命令并获取所花费的时间。此外，还有一个用于每个 TFS 命令的另一个 `.cmd` 文件。它会循环执行第一个文件，多次，针对所有必需的 TFS Proxy 状态。此外，对第一个命令文件的单次启动可以获取每个 TFS Proxy 状态的入站/出站流量。

在我的实验中，每个 TFS 命令都执行了四次。第一次尝试因实验纯洁性而被拒绝，而所有其他尝试的时间都被添加到了 Excel 文件中。因此，对于 'Get' 命令，执行了 16 次尝试（16 = 4 次尝试 x 4 个 TFS Proxy 状态）。然后，执行了其余 TFS 命令（'Check-Out'、'Undo Check-Out'、'Check-In'、'History'、'Diff'）的 `.cmd` 文件。之后，我更改了传输速率限制，并重新开始所有测试。

在实际情况中，TFS Server 是远程的，而 TFS Proxy Server 和 TFS Client 位于同一网络中。在我的测试环境中，所有计算机都位于同一网络（100 MBps）中，因此我决定使用 SoftPerfect Bandwidth Manager 来限制计算机-TFS Server 和 TFS Proxy Server-TFS Server 之间的传输速率，以模拟真实情况。

命令文件实现

注意：假定已创建用于测试存储库的工作区，并将其映射到本地路径（请参阅存档中的 `create local.cmd` 文件）。

下面，您可以看到 'Get' 命令的 `.cmd` 文件示例。

@ECHO OFF
setlocal

SET Getpath="C:\Temp\tfsProxyTest1"
ECHO Trying TFS get...
ECHO.

@IF NOT [%1]==[] (@echo set proxy
@set TFSPROXY=http://tfs_proxy_server:8081)

cd %Getpath%

REM get latest source from TFS
@set t1=%time%
@echo %TFSPROXY%
tf get %Getpath% /login:server\login,password /force /recursive 
echo %t1%
echo %time%

@set TFSPROXY=

ECHO.

ECHO TFS get completed...
endlocal

用于循环执行各种 TFS Proxy 状态下的 'Get' 命令的另一个 `.cmd` 文件

@echo OFF

echo Start: Operation GET

FOR /L %%G IN (1,1,4) DO (echo Start: without proxy
call start_get.cmd
echo End: without proxy
)

FOR /L %%G IN (1,1,4) DO (echo Start: Proxy 0% cached
call z:\delete.cmd
call start_get.cmd use_cache
echo End: Proxy 0% cached
)

FOR /L %%G IN (1,1,4) DO (echo Start: PROXY 100% cached
call start_get.cmd use_cache
echo End: PROXY 100% cached
)

FOR /L %%G IN (1,1,4) DO (echo Start: proxy 90% cached
call z:\delete_10percent.cmd
call start_get.cmd use_cache
echo End: proxy 90% cached
)

echo End: Operation GET

额外的 `.cmd` 文件 `delete_10percent.cmd` 和 `delete.cmd` 分别仅删除 10% 的缓存和全部缓存。

注意：所有 `.cmd` 文件均可在附件的存档中找到。

测试结果

我花了几天时间才完成所有测试（谢天谢地！）。详细结果已放在附件存档的 Excel 文件中。

'Get' 命令

注意：数据传输图中的柔和颜色对应于慢速通道，更亮的颜色对应于快速通道。

图 1 提供了关于 'Get' 操作数据传输的信息。从图中可以看出，'Proxy disabled'（禁用代理）和 'Proxy, 0% cached'（代理，0% 缓存）的操作速度较慢，而 'Proxy, 90% cached'（代理，90% 缓存）和 'Proxy, 100% cached'（代理，100% 缓存）则快得多。此信息与以下数据一致。

传输速率 / Proxy 状态	Proxy, 0% 缓存	Proxy disabled (禁用代理)	Proxy, 90% 缓存	Proxy, 100% 缓存
64/128 Kbps	05:22,62	05:15,52	01:40,71	01:29,99
128/256 Kbps	02:37,78	02:36,54	00:56,37	00:53,38
256/512 Kbps	01:22,83	01:19,51	00:42,55	00:39,97
512/1024 Kbps	00:43,33	00:40,74	00:31,35	00:27,94
1MBps/2MBps	00:30,05	00:26,13	00:24,70	00:23,88
2MBps/4MBps	00:25,40	00:20,93	00:21,95	00:20,71

结论

• 在慢速互联网通道速率下，TFS Proxy 帮助很大——整体性能几乎提高了四倍。
• 互联网通道速率会影响操作时间，但这种关系是非线性的。
• 对于 'Proxy enabled'（启用代理）和 'Proxy disabled'（禁用代理）模式，出站通道速率为 2 Mbps 时的差异约为 9%——我们还需要 TFS Proxy 吗？;-)
• 模式 'Proxy, 0% cached'（代理，0% 缓存）比 'Proxy disabled'（禁用代理）稍慢，因为前者需要从服务器获取数据，然后将其发送给客户端。

'Check-Out' 命令

图 3 提供了关于 'Check-Out' 操作数据传输的信息。从图中可以看出，它不使用 TFS Proxy。因此，我们只能测试 'Proxy disabled'（禁用代理）状态。

传输速率 / Proxy 状态	Proxy disabled (禁用代理)
64/128 Kbps	01:27,36
128/256 Kbps	00:52,93
256/512 Kbps	00:36,56
512/1024 Kbps	00:27,72
1MBps/2MBps	00:23,38
2MBps/4MBps	00:21,25

结论

• 使用 TFS Proxy 对 'Check-Out' 操作没有影响。
• 互联网通道速率会影响操作时间，但这种关系同样是非线性的。
• 出站通道速率为 1 Mbps 和 2 Mbps 之间的差异约为 15%——1 Mbps 和 2 Mbps 通道成本之间的差异是多少？

'Undo Check-Out' 命令

图 5 提供了关于 'Undo Check-Out' 操作数据传输的信息。从图中可以看出，它的视图与图 1 几乎相同。这意味着，'Proxy disabled'（禁用代理）和 'Proxy, 0% cached'（代理，0% 缓存）状态是最慢的，而 'Proxy, 90% cached'（代理，90% 缓存）和 'Proxy, 100% cached'（代理，100% 缓存）则快得多。请参阅下表和图以了解详情。

传输速率 / Proxy 状态	Proxy, 0% 缓存	Proxy disabled (禁用代理)	Proxy, 90% 缓存	Proxy, 100% 缓存
64/128 Kbps	05:22,51	05:16,05	01:43,53	01:33,25
128/256 Kbps	02:42,26	02:38,09	01:01,47	01:01,09
256/512 Kbps	01:29,40	01:22,54	00:41,22	00:40,35
512/1024 Kbps	00:47,11	00:42,63	00:33,82	00:31,52
1MBps/2MBps	00:34,21	00:30,46	00:27,86	00:25,81
2MBps/4MBps	00:28,09	00:25,27	00:25,26	00:23,60

结论

结论与 'Get' 操作完全相同。

'Check-In' 命令

图 7 提供了关于 'Check-In' 操作数据传输的信息。从图中可以看出，它不使用 TFS Proxy。因此，我们只能测试 'Proxy disabled'（禁用代理）状态。

表 5：'Check-In' 操作的执行时间（分:秒）。

传输速率 / Proxy 状态	Proxy disabled (禁用代理)
64/128 Kbps	01:07,15
128/256 Kbps	00:30,14
256/512 Kbps	00:17,13
512/1024 Kbps	00:10,87
1MBps/2MBps	00:07,51
2MBps/4MBps	00:06,49

结论

结论与 'Check-Out' 操作完全相同。

'History' 命令

图 9 提供了关于 'History' 操作数据传输的信息。从图中可以看出，它不使用 TFS Proxy。因此，我们只能测试 'Proxy disabled'（禁用代理）状态。

传输速率 / Proxy 状态	Proxy disabled (禁用代理)
64/128 Kbps	01:36,80
128/256 Kbps	00:49,42
256/512 Kbps	00:25,71
512/1024 Kbps	00:14,09
1MBps/2MBps	00:08,43
2MBps/4MBps	00:05,89

结论

结论与 'Check-Out' 和 'Check-In' 操作完全相同。

'Diff' 命令

图 11 提供了关于 'Diff' 操作数据传输的信息。从图中可以看出，它的视图与图 1 和图 5 略有不同。慢速和快速通道传输的数据量相当。因此，'Proxy enabled'（启用代理）和 'Proxy disabled'（禁用代理）之间的差异应该比 'Get' 和 'Undo Check-Out' 操作小。让我们看看下面的表和图以了解详情。

传输速率 / Proxy 状态	Proxy, 0% 缓存	Proxy disabled (禁用代理)	Proxy, 90% 缓存	Proxy, 100% 缓存
64/128 Kbps	01:21,03	01:15,37	00:48,40	00:46,49
128/256 Kbps	00:41,01	00:37,61	00:32,16	00:29,44
256/512 Kbps	00:30,25	00:23,25	00:23,87	00:20,80
512/1024 Kbps	00:28,58	00:19,87	00:19,11	00:16,91
1MBps/2MBps	00:24,50	00:16,65	00:16,65	00:14,50
2MBps/4MBps	00:22,68	00:15,91	00:15,48	00:13,36

结论

• 在慢速互联网通道速率下，TFS Proxy 有很大帮助——整体性能几乎提高了一倍。但比 'Get' 和 'Undo Check-Out' 操作要差。
• 互联网通道速率会影响操作时间，并且是一种非线性依赖关系。
• 对于 'Proxy enabled'（启用代理）和 'Proxy disabled'（禁用代理）模式，出站通道速率为 512 Kbps 时的差异约为 10%。
• 在任何通道速率下，'Proxy, 0% cached'（代理，0% 缓存）模式都比其他模式慢得多。

总体结论

'Check-out'（签出）、'Check-In'（签入）和 'History'（历史记录）操作

• 使用 TFS Proxy 对这些操作没有影响。

'Get' 操作

• 似乎即使对于 'Proxy, 100% cached'（代理，100% 缓存）模式，传输的数据量也太大了，除了 TFS Proxy 之外——总入站数据量约有三分之一必须直接从 TFS Server 通过慢速通道获取。

'Undo Check-Out' 操作

• 直接发送到 TFS Server 的数据量很小——这是可以理解的。
• 直接从 TFS Server 接收的数据量巨大——几乎是从 TFS Proxy 接收量的一半。不清楚 TFS 为什么这样工作。
• 总的来说，'Get' 操作传输的数据量更大。这不合逻辑，例如，SVN 版本控制系统在执行 'Undo' 操作时无需与服务器通信。

'Diff' 操作

• 直接发送到 TFS Server 的数据量很小——这是可以理解的。
• 直接从 TFS Server 接收的数据量巨大——几乎是从 TFS Proxy 接收量的一半。
• 'Diff' 操作使用了 `/brief` 选项执行。简要格式会打印被比较的文件是否不同。根据测试，对于 'Get' 和 'Undo Check-Out' 操作，接收了 4.7 MB 和 5.2 MB。但 'Diff' 操作接收了约 1 MB，这太多了，因为要比较的文件大小约为 1.47 MB。客户端和代理计算机之间传输的数据量约为 0.5 MB，这是被比较文件大小的三分之一。看来，其余传输的数据是服务信息。
• 再次，TFS 不是一个最优化的系统，例如，Subversion 在执行两个文件版本之间的差异时不需要接收任何信息。

因此，对于所有操作：

• 如果缓存一直为空（无论出于何种原因），您都应该避免使用 TFS Proxy。
• 如果缓存为空，TFS Proxy 会从 TFS Server 获取所有数据，然后将其发送给客户端。
• TFS Client 始终会（除了 TFS Proxy 之外）直接向 TFS Server 发送和接收一部分信息。信息量很大，并且会影响 TFS 的整体性能。因此，如果我们能减少传输的服务信息量，就可以提高性能。
• 某些操作的实现不如其他一些版本控制系统优化，部分原因是 TFS 的架构。

结果

TFS Proxy 非常棒。:-)

它加速了某些高使用率的操作（'Get'、'Undo Check-Out'、'Diff'）的速度，并且对于带宽受限的入站互联网通道尤其有用。不幸的是，TFS Client 除了 TFS Proxy 之外，还向 TFS Server 发送了大量流量。某些操作根本不使用 TFS Proxy（'Check-Out'、'Check-In'、'History'）。保持每天观察缓存数据的饱满度以获得最大性能非常重要。入站互联网通道对性能不重要。

希望这有帮助。

谁可以使用它？

任何使用远程 TFS Server 的开发团队。

已知问题

我不知道。

致谢

感谢以下帮助过我的人：

• Alex Maskaev
• Victor Belyavskiy

历史

• 版本 1.0 (2008-08-13) - 初始发布。