產品中（基於ASP.NET MVC開發）需要經常對藥品名稱及名稱拼音碼進行下拉匹配及結果查詢。為了加快查詢的速度，所以我最開始就將其加入記憶體中（大約有六萬五千條資料）。
下面附實體類。
|
1 2 3 4 5 6 7 8 9 10 11 |
public class drugInfo { public int drug_nameid { get; set; } public string drug_name { get; set; } public string drug_search_code { get; set; } } |
第一次做法：
|
1 2 3 4 5 6 7 8 |
Stopwatch stopWatch = new Stopwatch(); stopWatch.Start(); key = key.ToLower(); var resultList = cacheList.Where(m => m.drug_name.ToLower().Contains(key) || m.drug_search_code.ToLower().Contains(key)).ToList(); stopWatch.Stop(); double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds); |
重新整理頁面幾次，得到個平均用時約35MS左右。
第二次做法：
為了減少CPU的運算，我們將LINQ表示式中的轉小寫操作優化一下，先在快取列表上做些動作，將名稱和搜尋碼先轉小寫儲存。
下面為改進過的實體類。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
public class drugInfo { public int drug_nameid { get; set; } public string drug_name { get; set; } public string drug_search_code { get; set; } public string lower_drug_name { get; set; } public string lower_drug_search_code { get; set; } } Stopwatch stopWatch = new Stopwatch(); stopWatch.Start(); key = key.ToLower(); var resultList = cacheList.Where(m => m.lower_drug_name.Contains(key) || m.lower_drug_search_code.Contains(key)).ToList(); stopWatch.Stop(); double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds); ViewBag.useTime = string.Format("用時{0}秒rn", eMseconds); |
重新整理頁面幾次，得到個平均用時約16MS左右。
雖然這樣做，記憶體列表中會多一些冗餘資料，但是得到的效能提升有一倍了。
第三次做法：
啟用PLINQ的平行計算，平行計算是NET4.0的特性，可以利用CPU多核的處理能力，提高運算效率，但是不一定是成倍的
LIST等泛型啟用平行計算很簡單，使用AsParallel()即可，改進如下：
|
1 2 3 4 5 6 7 8 9 |
Stopwatch stopWatch = new Stopwatch(); stopWatch.Start(); key = key.ToLower(); var resultList = cacheList.AsParallel().Where(m => m.lower_drug_name.Contains(key) || m.lower_drug_search_code.Contains(key)).ToList(); stopWatch.Stop(); double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds); ViewBag.useTime = string.Format("用時{0}秒rn", eMseconds); |
同樣，我們多重新整理頁面幾次，獲得的平均時間為10MS左右。
當然，寫到這裡，大家以為這次的優化就結束了，至少我當時是這麼想的。
但是事實上，碰到了一個大麻煩。
由於產品執行於伺服器IIS上面，使用AsParallel並行特性時（預設情況下，到底使用多少個執行緒來執行PLINQ是在程式執行時由TPL決定的。但是，如果你需要限制執行PLINQ查詢的執行緒數目（通常需要這麼做的原因是有多個使用者同時使用系統，為了伺服器能同時服務儘可能多的使用者，必須限制單個使用者佔用的系統資源），我們可以使用ParallelEnumerable. WithDegreeOfParallelism()擴充套件方法達到此目的。），客戶端一個請求就佔用了過多的系統資源，導致應用程式池假死。無法提供服務。
我也嘗試過使用WithDegreeOfParallelism設定了一個相對較少的值，但是在使用LOADRUNNER來開啟200個併發的時候，也會產生假死的情況，於是，不得不嘗試下面第四步的辦法。
第四次做法：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Stopwatch stopWatch = new Stopwatch(); stopWatch.Start(); key = key.ToLower(); ConcurrentBag resultList = new ConcurrentBag(); Parallel.For(0, cacheList.Count, new ParallelOptions { MaxDegreeOfParallelism = 4 }, (i) => { var item = cacheList[i]; if (item.lower_drug_name.Contains(key) || item.lower_drug_search_code.Contains(key)) { resultList.Add(item); } }); stopWatch.Stop(); double eMseconds = Math.Max(0, stopWatch.Elapsed.TotalSeconds); ViewBag.useTime = string.Format("用時{0}秒rn", eMseconds); |
時間與第三步沒有什麼區別，但是這樣做解決了併發時，應用程式池假死的問題。至此，困擾兩天的問題完美解決，雖然使用Parallel.For會帶來結果亂序的問題，但是結果數量已經不多了，再次排序也沒有什麼關係了。
具體原因參見下面：
ParallelOptions.MaxDegreeOfParallelism指明一個並行迴圈最多可以使用多少個執行緒。TPL開始排程執行一個並行迴圈時，通常使用的是執行緒池中的執行緒，剛開始時,如果執行緒池中的執行緒很忙,那麼,可以為並行迴圈提供數量少一些的執行緒（但此數目至少為1，否則並行任務無法執行，必須阻塞等待）。等到執行緒池中的執行緒完成了一些工作,則分配給此並行迴圈的執行緒數目就可以增加，從而提升整個任務完成的速度，但最多不會超過ParallelOptions.MaxDegreeOfParallelism所指定的數目。
PLINQ的WithDegreeOfParallelism()則不一樣，它必須明確地指出需要使用多少個執行緒來完成工作。當PLINQ查詢執行時，會馬上分配指定數目的執行緒執行查詢。
之所以PLINQ不允許動態改變執行緒的數目，是因為許多PLINQ查詢是“級聯”的，為保證得到正確的結果，必須同步參與的多個執行緒。如果執行緒數目不定，則要實現執行緒同步非常困難。