最近在工作上碰到一個性能問題，由于項目是基于SOA的架構，使得整個系統(tǒng)完全依賴于各種各樣的Service，其中用于處理業(yè)務邏輯的Business Services全部都用.NET Workflow 3.5實現（歷史原因，項目還沒升級到Workflow 4）。在眾多的Business Service中，其中有一個的主要功能是，通過調用不同的Data Service來獲取數據，然后根據業(yè)務邏輯來組織這些數據并返回給它的調用者。該Business Service的工作流（Workflow）主要包含三個活動組件（Activity），大致可以用下圖表示：

需要說明一下，在實際項目中，這個Workflow本身不僅僅只是簡單地包含上面三個Activity，通過性能測試的數據分析，瓶頸就在這三個Activity上，而每個Activity的執(zhí)行時間又主要消耗在反復調用Data Service上。在此，為了簡化問題的描述，我把其它不相干的Activity剔除了，于是就得到了上圖的結構。

圖中的三個Activity都會分別去調用不同的Data Service來獲得數據，尤其在getNotesActivity中，Data Service會被循環(huán)調用，這使得系統(tǒng)性能大打折扣。原本有一個解決方案可以在一定程度上提高getNotesActivity的效率，就是修改被調用的Data Service，使得它能夠一次性接收多個request的數據，處理完之后再將所有的結果一次性返回，這樣就避免了Data Service的循環(huán)調用，有效地減少了數據在網絡上的來回次數。但是，這種解決方案需要更改Data Service的Request Schema，這個改動是很大的，因為可能有很多其它的Business Service都在調用這個Data Service，牽涉的范圍太廣了。

根據實際項目，稍加分析不難發(fā)現，這個Workflow中的Activity有如下幾個特點：

三個Activity的輸入屬性參數都來自于Workflow（即通過與Workflow中定義的DependencyProperty進行綁定而獲得數據），并不存在下游的Activity的輸入參數需要依賴上游Activity的輸出參數的情況

每個Activity的輸出屬性參數都只關注某一種類型的數據，在Workflow Runtime執(zhí)行完某個Activity后，也會通過DependencyProperty將處理結果傳遞給Workflow，而這些輸出屬性參數之間也并沒有任何關聯

三個Activity所調用的Data Service也比較獨立，基本上可以說是在做三個完全不同的工作

時間主要消耗在Data Service的調用上，不存在由于復雜的運算邏輯導致CPU利用率近似100%的情況，也不存在由于物理內存用完而需要頻繁讀寫虛擬內存的情形

上述的幾個特點中，第四點為我們引入多線程或并行任務處理提供了主要依據。這里需要額外岔開一下。有很多軟件人員認為，多線程一定能夠提高系統(tǒng)性能，因為事務可以分派到多個線程中進行并行處理。我覺得，應該這樣去看待這個問題：首先，根據Martin Fowler的《企業(yè)應用架構模式》（也就是著名的PoEAA）一書中有關性能的討論認為，有很多術語可以描述性能，比如：響應時間、響應性、等待時間、吞吐率、負載、負載敏感度等。假設完成某個任務需要的時間很長，比如需要5秒，那么其響應時間就是5秒，而如果讓用戶等待這5秒過去后，再將系統(tǒng)的控制權交給用戶，就會讓用戶明顯感覺很不順，于是響應性就很差；但如果能將這個任務交給另一個執(zhí)行體去處理，而程序本身直接將系統(tǒng)控制權交給用戶，等那個執(zhí)行體完成任務處理后，再將結果提供給用戶，那么，同樣處理這個任務需要5秒鐘，這種方式的響應性就明顯要好于前者，這也是我們以前做Windows Forms開發(fā)的時候，要把耗時的處理交給另一個線程處理，以不至于因為主線程的阻塞而導致界面凍結的尷尬局面。因此，多線程的引入，可以提高系統(tǒng)的響應性。

其次，多線程是否能夠提高系統(tǒng)的響應時間？這也未必，在單核處理器上，多線程是采用時間片輪循的方式實現的，也就是說，相同時間點上，只有一個線程在執(zhí)行，只不過是時間片足夠小，輪循頻率足夠高，才讓我們感覺線程是并行執(zhí)行的，在這樣一種體系結構下，完成任務的處理還是需要那么長時間，甚至時間片的切換倒還會帶來額外的開銷。在多核系統(tǒng)中，或許真的可以提高響應時間，不過我目前沒有實際的測試數據用來比較，因此在這個問題上，我還沒有足夠的發(fā)言權。

而對于目前項目的情況，Data Service是分布在網絡上不同位置的資源，如果能讓這些Data Service同時處理數據請求，再讓Business Service去組織分別來自這些Data Service的處理結果，那么整個Business Service的響應時間是可以明顯提高的，響應時間提高了，響應性也同樣提高了。假設***個Activity耗時t1，第二個Activity耗時t2，第三個Activity耗時t3，那么，如果按上圖中的順序方式執(zhí)行，Business Service的響應時間就是t1+t2+t3。但如果讓這些Activity并行處理（也就相當于并行調用Data Service使其同時處理數據請求），那么Business Service的響應時間應該就是max(t1, t2, t3)。

于是，我打算將上述的Workflow修改一下，采用多線程的方式來分別運行每個Activity，***再將結果匯總。我修改后的Workflow如下所示：

在此需要對ParallelActivity說明一下。.NET Workflow 3.5的ParallelActivity并沒有做到所謂的“并行執(zhí)行”，因為Workflow Runtime是在單獨的線程上執(zhí)行Workflow Instance的，因此，要讓多個Activity真正并行執(zhí)行是做不到的。ParallelActivity的真正用意在于協調每個分支中的SequenceActivity（注意：ParallelActivity的每個分支只能接收一個SequenceActivity），使得其中的每個Activity都有一次執(zhí)行的機會。某個分支中的一個活動執(zhí)行過后，就會輪到下一個分支。當這個分支執(zhí)行了一個活動后，執(zhí)行又會轉移到再下一個分支，以此類推。當所有分支都有了執(zhí)行機會之后，又會從***個（最左側）分支開始這一過程，繼續(xù)執(zhí)行***個分支的下一個活動（如果存在的話）。因此，在我們的這個例子中，完全可以不用ParallelActivity，而仍然選擇原來的結構即可。之前我并沒有完全清楚地了解ParallelActivity，開始一直以為ParallelActivity的意思是，讓Workflow Runtime同時安排（Schedule）每個分支的執(zhí)行，以便當每個分支都以異步方式運行時，所有的分支可以實現并行處理。不過也不要緊，在這里使用ParallelActivity，雖然沒有有效地利用它的特性，但與原來的Workflow相比，從可讀性上講，這種結構更容易讓人覺得這是一種并行的運行方式。

另一個變化是，原本每個操作都是寫在一個自定義的Activity中的，通過重寫Activity的Execute方法來做業(yè)務處理，而現在則是用CodeActivity來代替原來的Activity，這樣做的好處是，可以將業(yè)務處理的代碼放在同一個Context中，這也為線程同步提供了便利，降低了使用線程的復雜度。

以下是改進后的Workflow的代碼，供參考。

using System;  
using System.Collections.Generic;  
using System.Threading;  
using System.Workflow.Activities;  
namespace WorkflowConsoleApplication3  
{  
    public sealed partial class Workflow1 : SequentialWorkflowActivity  
    {  
        List<Thread> threads = new List<Thread>();  
       public Workflow1()  
        {  
            InitializeComponent();  
        }  
        private void getAdditionalInfoActivity_Execute(object sender, EventArgs e)  
        {  
            var t1 = new Thread(() =>  
                {  
                    // Call Data Service 1 to implement business logic...  
                });  
            threads.Add(t1);  
            t1.Start();  
        }  
        private void getNotesActivity_Execute(object sender, EventArgs e)  
        {  
            var t2 = new Thread(() =>  
                {  
                    // Call Data Service 2 in a loop to implement business  
                    // logic...  
                });  
            threads.Add(t2);  
            t2.Start();  
        }  
 
        private void getSpecialPointsActivity_Execute(object sender, EventArgs e)  
        {  
            var t3 = new Thread(() =>  
                {  
                    // Call Data Service 3 to implement business logic...  
                });  
            threads.Add(t3);  
            t3.Start();  
        }  
   
        private void syncCodeActivity_Execute(object sender, EventArgs e)  
        {  
            // Wait for all threads to terminate...  
            threads.ForEach(p => p.Join());  
            // TODO: Process with results and exceptions  
        }  
    }  
}  
從上面的代碼中可以看到，每個 

從上面的代碼中可以看到，每個CodeActivity在執(zhí)行的時候都會啟動一個線程，這個線程會調用相應的Data Service來實現其業(yè)務邏輯，線程創(chuàng)建以后，會被保存在一個線程列表里，用來在syncCodeActivity中進行線程同步。syncCodeActivity則通過線程的Join方法來等待所有線程全部完成各自的工作，***對運行結果和異常進行處理。

此處線程的運用需要遵循.NET線程使用的***實踐，應該盡量避免線程的阻塞，在訪問臨界資源的時候應作加鎖處理以防止狀態(tài)異常。由于在這個例子中，每個線程又會牽涉到其它Service的調用，因此在線程中捕獲的異常，我建議還是先將其記錄下來，然后“溫和”地直接使用return語句終止線程執(zhí)行，而不是隨意拋出異常而使得線程進入一個不確定的狀態(tài)。當然，讀者朋友如果在多線程環(huán)境中有處理異常的經驗，也懇請在本文留言指導。

對Workflow進行調整之后，重新編譯、部署并運行這個Business Service，然后用已經寫好的Client程序進行測試，我們得到了如下的結果（幾個明顯的噪音數據已經被劃掉，沒有包含在統(tǒng)計中）。從這個報表可以看到，針對我們的這個案例，在Workflow中引入多線程的確可以明顯地提高系統(tǒng)性能。

原文鏈接：http://www.cnblogs.com/daxnet/archive/2011/02/21/1959423.html