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

发表于:2013-09-04来源:ALM Networks作者:Lei Xu点击数: 标签:TFS
让我们继续这个真实的项目故事,上一篇中的两个经验都是关于非技术因素的,下面的这些可能技术人员会更感兴趣。 经验3:为你的TFS数据创建索引

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

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

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

  TIP: 参考SSW Rules to Better SQL Server Databases

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

tfstuneindex

  图:对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的动态计算等因素,这将是怎样一个漫长的查询过程?

iisgarden-1

  上面这张截图中大家看到的就是在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/