我們如何使用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/