我们如何使用TFS在我们的研发中

　　更新：Adam Cogan 发布了本篇博客的英文版。

　　让我们继续这个真实的项目故事，上一篇中的两个经验都是关于非技术因素的，下面的这些可能技术人员会更感兴趣。

　　经验3：为你的TFS数据创建索引

　　TIP: 参考SSW Rules to Better SQL Server Databases

　　使用数据索引是SQL数据库性能优化的基本方法之一。不过，大家应该知道对于TFS的数据库来说，直接对其中的数据结构进行修改是不推荐的方式，所以大多数人不会意识到其实我们可以对TFS数据库建立索引。

　　图：对TFS数据建立索引后的性能提升非常明显

　　对于我们的应用来说，有2个定制的工作项字段非常频繁的被搜索，因此我们在这2个字段上添加了索引，这使得相关操作的整体性能提高了3倍左右。

　　以下是对工作项字段添加索引的命令：

　　witadmin indexfield /collection:CollectionURL /n:Name /index:on|off

　　witadmin是TFS所提供的工作项类型的后台操作命令，可以通过以下MSDN页面找到更多的信息：

　　http://msdn.microsoft.com/en-us/library/dd236909.aspx

　　经验4：在高性能系统上应该尽量避免使用虚拟化

　　在虚拟化火热的今天，大家都会认为使用Hyper-V来优化服务器基础架构是件好事，但是我们发现对于TFS的数据层服务器来说，由于大量的磁盘I/O操作，虚拟化会对服务器性能造成严重的影响，应该尽量避免。

　　在我们的项目中，将TFS数据层服务器迁移至硬件是我们在基础架构上所采取的首选措施，仅仅这一项就将相关操作的整体性能提升了2倍左右。请参考以下链接了解更多的信息：

　　http://msdn.microsoft.com/en-us/library/ms143506%28v=sql.105%29.aspx

　　说明：在迁移至硬件服务器之前，我们也对Hyper-V Pass-through磁盘进行了测试，但是结果并不让人满意，虽然Pass-through磁盘相对普通的VHD(动态或静态)来说确实提供了更好的 I/O性能，但是仍然无法满足我们的性能要求。关于Pass-through磁盘的性能测试请参考：

　　http://clusteringformeremortals.com/2009/09/25/hyper-v-pass-through-disk-performance-vs-fixed-size-vhd-files-and-dynamic-vhd-files-in-windows-server-2008-r2/

　　经验5：将数据库的日志文件单独放置于不同的物理磁盘

　　这个建议并不新鲜，任何的SQL性能调优的指导都会建议将SQL数据库的 数据/日志/临时文件 分别放置于不同的物理磁盘;这样SQL Server可以将I/O请求通过不同的硬件完成，从而提升性能。参考资料：

　　http://www.codeproject.com/Articles/43629/Top-10-steps-to-optimize-data-access-in-SQL-Server

　　经验6：在IIS 上激活Web Garden (maxProcesses) 设置

　　警告：一般来说，这一设置对于99%的应用来说并不推荐，但我们很幸运的属于那1%。其中的原因比较复杂，大家感兴趣可以参考：http://blogs.iis.net/chrisad/archive/2006/07/14/1342059.aspx

　　对于IIS来说，默认的设置会对同时处理的并发请求数量进行限制，并将无法处理的请求放入队列中等待，这意味着如果单个请求的事务处理时间过长，我们会有很长的等待队列。按照以上引用的IIS博客中的说法，Web Garden功能的设计目的只有一个

　　“为那些不存在计算依赖，但是会运行很长时间的请求提供扩展能力，从而避免消耗掉所有的工作进程。”

　　(这个话确实很难理解，你可能需要好好琢磨一下，另外看看我下面对TFS应用层的分析也会帮助你理解。)

　　现在的问题是，为什么TFS属于这幸运的1%而有别与一般的Web应用程序?

　　首先大家要明白的是，虽然TFS看上去很复杂，其实对于用户来说它就是一堆的Web Service而已。与一般应用不同的是TFS使用了大量的“动态数据结构”。所谓动态数据结构，就是在应用设计完成以后，仍然允许用户根据需要扩展更多地数据域。在TFS中大量使用了这种技术，这也是为什么我们可以对工作项字段进行定制的原因。不过，这种灵活性造成的结果是在SQL Server上所执行的查询操作会复杂得多，而且会随着你所添加的定制量的增加而变得越发复杂。想象一下：你添加了定制字段的工作项如果要被提取出来，那么TFS应用层所生成的查询需要被动态生成，而在SQL Server中所需要的行列转换的复杂度也会随之增加，如果考虑Query Plan的动态计算等因素，这将是怎样一个漫长的查询过程?

　　上面这张截图中大家看到的就是在IIS在收到大量并发操作时候所生成的队列。一般来说，任何>50ms的请求都已经是慢得要死了，而我们的队列中竟然有125ms的天文数字。另外大家需要注意的是所有这些请求都处于ExecuteRequest状态，意味着IIS正在等待后端程序的处理完成。

　　经过以上分析后，我们得出的结论是，在满足以下2个条件的情况下你可以使用Web Garden来改进性能：

　　1. 你的应用没有使用 InProcess Session

　　2. 你的应用是无状态的(可能你会觉得和第1点重复，其实不完全是)

　　幸运的是，TFS应用层的Web服务完全满足以上条件，这也是为什么我们可以在TFS上很容易的实现NLB(网络负载均衡)，而不需要额外的设置的原因。

　　决定使用Web Garden以后，下一个问题是我们应该使用多少用户进程(Worker Process)?

　　其实这个问题很难回答，在实际中我们也是不停地试出来的，影响的因素其实很多，比如：硬件本身的配置，应用被调用的场景等等。不过一个相对通用的建议是，不要超过你的CPU物理核的数量，这是因为CPU用来调度不同的工作进程的开销会抵消掉可能获得的性能提升。

　　因此，一般的建议是maxprocess = (CPU物理核数量) -1

　　(看到经验3里面的Worker Process数量为7了么?那是因为我们使用了8核的CPU)

原文转自：http://www.almnetworks.net/wp/2013/07/21/tfs-is-huge-in-china-part2/