|
|
最近在工作上碰到一個性能問題，由于項目是基于SOA的架構(gòu)，使得整個系統(tǒng)完全依賴于各種各樣的Service，其中用于處理業(yè)務(wù)邏輯的Business Services全部都用.NET Workflow 3.5實現(xiàn)（歷史原因，項目還沒升級到Workflow 4）。在眾多的Business Service中，其中有一個的主要功能是，通過調(diào)用不同的Data Service來獲取數(shù)據(jù)，然后根據(jù)業(yè)務(wù)邏輯來組織這些數(shù)據(jù)并返回給它的調(diào)用者。該Business Service的工作流（Workflow）主要包含三個活動組件（Activity），大致可以用下圖表示：
需要說明一下，在實際項目中，這個Workflow本身不僅僅只是簡單地包含上面三個Activity，通過性能測試的數(shù)據(jù)分析，瓶頸就在這三個Activity上，而每個Activity的執(zhí)行時間又主要消耗在反復(fù)調(diào)用Data Service上。在此，為了簡化問題的描述，我把其它不相干的Activity剔除了，于是就得到了上圖的結(jié)構(gòu)。
圖中的三個Activity都會分別去調(diào)用不同的Data Service來獲得數(shù)據(jù)，尤其在getNotesActivity中，Data Service會被循環(huán)調(diào)用，這使得系統(tǒng)性能大打折扣。原本有一個解決方案可以在一定程度上提高getNotesActivity的效率，就是修改被調(diào)用的Data Service，使得它能夠一次性接收多個request的數(shù)據(jù)，處理完之后再將所有的結(jié)果一次性返回，這樣就避免了Data Service的循環(huán)調(diào)用，有效地減少了數(shù)據(jù)在網(wǎng)絡(luò)上的來回次數(shù)。但是，這種解決方案需要更改Data Service的Request Schema，這個改動是很大的，因為可能有很多其它的Business Service都在調(diào)用這個Data Service，牽涉的范圍太廣了。
根據(jù)實際項目，稍加分析不難發(fā)現(xiàn)，這個Workflow中的Activity有如下幾個特點：
- 三個Activity的輸入屬性參數(shù)都來自于Workflow（即通過與Workflow中定義的DependencyProperty進行綁定而獲得數(shù)據(jù)），并不存在下游的Activity的輸入?yún)?shù)需要依賴上游Activity的輸出參數(shù)的情況
- 每個Activity的輸出屬性參數(shù)都只關(guān)注某一種類型的數(shù)據(jù)，在Workflow Runtime執(zhí)行完某個Activity后，也會通過DependencyProperty將處理結(jié)果傳遞給Workflow，而這些輸出屬性參數(shù)之間也并沒有任何關(guān)聯(lián)
- 三個Activity所調(diào)用的Data Service也比較獨立，基本上可以說是在做三個完全不同的工作
- 時間主要消耗在Data Service的調(diào)用上，不存在由于復(fù)雜的運算邏輯導(dǎo)致CPU利用率近似100%的情況，也不存在由于物理內(nèi)存用完而需要頻繁讀寫虛擬內(nèi)存的情形
上述的幾個特點中，第四點為我們引入多線程或并行任務(wù)處理提供了主要依據(jù)。這里需要額外岔開一下。有很多軟件人員認為，多線程一定能夠提高系統(tǒng)性能，因為事務(wù)可以分派到多個線程中進行并行處理。我覺得，應(yīng)該這樣去看待這個問題：首先，根據(jù)Martin Fowler的《企業(yè)應(yīng)用架構(gòu)模式》（也就是著名的PoEAA）一書中有關(guān)性能的討論認為，有很多術(shù)語可以描述性能，比如：響應(yīng)時間、響應(yīng)性、等待時間、吞吐率、負載、負載敏感度等。假設(shè)完成某個任務(wù)需要的時間很長，比如需要5秒，那么其響應(yīng)時間就是5秒，而如果讓用戶等待這5秒過去后，再將系統(tǒng)的控制權(quán)交給用戶，就會讓用戶明顯感覺很不順，于是響應(yīng)性就很差；但如果能將這個任務(wù)交給另一個執(zhí)行體去處理，而程序本身直接將系統(tǒng)控制權(quán)交給用戶，等那個執(zhí)行體完成任務(wù)處理后，再將結(jié)果提供給用戶，那么，同樣處理這個任務(wù)需要5秒鐘，這種方式的響應(yīng)性就明顯要好于前者，這也是我們以前做Windows Forms開發(fā)的時候，要把耗時的處理交給另一個線程處理，以不至于因為主線程的阻塞而導(dǎo)致界面凍結(jié)的尷尬局面。因此，多線程的引入，可以提高系統(tǒng)的響應(yīng)性。
其次，多線程是否能夠提高系統(tǒng)的響應(yīng)時間？這也未必，在單核處理器上，多線程是采用時間片輪循的方式實現(xiàn)的，也就是說，相同時間點上，只有一個線程在執(zhí)行，只不過是時間片足夠小，輪循頻率足夠高，才讓我們感覺線程是并行執(zhí)行的，在這樣一種體系結(jié)構(gòu)下，完成任務(wù)的處理還是需要那么長時間，甚至?xí)r間片的切換倒還會帶來額外的開銷。在多核系統(tǒng)中，或許真的可以提高響應(yīng)時間，不過我目前沒有實際的測試數(shù)據(jù)用來比較，因此在這個問題上，我還沒有足夠的發(fā)言權(quán)。
而對于目前項目的情況，Data Service是分布在網(wǎng)絡(luò)上不同位置的資源，如果能讓這些Data Service同時處理數(shù)據(jù)請求，再讓Business Service去組織分別來自這些Data Service的處理結(jié)果，那么整個Business Service的響應(yīng)時間是可以明顯提高的，響應(yīng)時間提高了，響應(yīng)性也同樣提高了。假設(shè)第一個Activity耗時t1，第二個Activity耗時t2，第三個Activity耗時t3，那么，如果按上圖中的順序方式執(zhí)行，Business Service的響應(yīng)時間就是t1+t2+t3。但如果讓這些Activity并行處理（也就相當(dāng)于并行調(diào)用Data Service使其同時處理數(shù)據(jù)請求），那么Business Service的響應(yīng)時間應(yīng)該就是max(t1, t2, t3)。
于是，我打算將上述的Workflow修改一下，采用多線程的方式來分別運行每個Activity，最后再將結(jié)果匯總。我修改后的Workflow如下所示：
在此需要對ParallelActivity說明一下。.NET Workflow 3.5的ParallelActivity并沒有做到所謂的并行執(zhí)行，因為Workflow Runtime是在單獨的線程上執(zhí)行Workflow Instance的，因此，要讓多個Activity真正并行執(zhí)行是做不到的。ParallelActivity的真正用意在于協(xié)調(diào)每個分支中的SequenceActivity（注意：ParallelActivity的每個分支只能接收一個SequenceActivity），使得其中的每個Activity都有一次執(zhí)行的機會。
某個分支中的一個活動執(zhí)行過后，就會輪到下一個分支。當(dāng)這個分支執(zhí)行了一個活動后，執(zhí)行又會轉(zhuǎn)移到再下一個分支，以此類推。當(dāng)所有分支都有了執(zhí)行機會之后，又會從第一個（最左側(cè)）分支開始這一過程，繼續(xù)執(zhí)行第一個分支的下一個活動（如果存在的話）。因此，在我們的這個例子中，完全可以不用ParallelActivity，而仍然選擇原來的結(jié)構(gòu)即可。之前我并沒有完全清楚地了解ParallelActivity，開始一直以為ParallelActivity的意思是，讓W(xué)orkflow Runtime同時安排（Schedule）每個分支的執(zhí)行，以便當(dāng)每個分支都以異步方式運行時，所有的分支可以實現(xiàn)并行處理。
不過也不要緊，在這里使用ParallelActivity，雖然沒有有效地利用它的特性，但與原來的Workflow相比，從可讀性上講，這種結(jié)構(gòu)更容易讓人覺得這是一種并行的運行方式。
另一個變化是，原本每個操作都是寫在一個自定義的Activity中的，通過重寫Activity的Execute方法來做業(yè)務(wù)處理，而現(xiàn)在則是用CodeActivity來代替原來的Activity，這樣做的好處是，可以將業(yè)務(wù)處理的代碼放在同一個Context中，這也為線程同步提供了便利，降低了使用線程的復(fù)雜度。
以下是改進后的Workflow的代碼，供參考。
1. using System;
2. using System.Collections.Generic;
3. using System.Threading;
4. using System.Workflow.Activities;
5. namespace WorkflowConsoleApplication3
6. {
7. public sealed partial class Workflow1 : SequentialWorkflowActivity
8. {
9. List<Thread> threads = new List<Thread>();
10. public Workflow1()
11. {
12. InitializeComponent();
13. }
14. private void getAdditionalInfoActivity_Execute(object sender, EventArgs e)
15. {
16. var t1 = new Thread(() =>
17. {
18. // Call Data Service 1 to implement business logic...
19. });
20. threads.Add(t1);
21. t1.Start();
22. }
23. private void getNotesActivity_Execute(object sender, EventArgs e)
24. {
25. var t2 = new Thread(() =>
26. {
27. // Call Data Service 2 in a loop to implement business
28. // logic...
29. });
30. threads.Add(t2);
31. t2.Start();
32. }
33.
34. private void getSpecialPointsActivity_Execute(object sender, EventArgs e)
35. {
36. var t3 = new Thread(() =>
37. {
38. // Call Data Service 3 to implement business logic...
39. });
40. threads.Add(t3);
41. t3.Start();
42. }
43.
44. private void syncCodeActivity_Execute(object sender, EventArgs e)
45. {
46. // Wait for all threads to terminate...
47. threads.ForEach(p => p.Join());
48. // TODO: Process with results and exceptions
49. }
50. }
51. }
52. 從上面的代碼中可以看到，每個
NET技術(shù)：在.NET Workflow 3.5中使用多線程提高工作流性能，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
