程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> 關於C語言 >> C# PLINQ 內存列表查詢優化歷程

C# PLINQ 內存列表查詢優化歷程

編輯:關於C語言

產品中(基於ASP.Net MVC開發)需要經常對藥品名稱及名稱拼音碼進行下拉匹配及結果查詢。為了加快查詢的速度,所以我最開始就將其加入內存中(大約有六萬五千條數據)。

下面附實體類。

? 1 2 3 4 5 6 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 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 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}秒\r\n", eMseconds);

刷新頁面幾次,得到個平均用時約16MS左右。

雖然這樣做,內存列表中會多一些冗余數據,但是得到的性能提升有一倍了。

第三次做法:

啟用PLINQ的並行計算,並行計算是NET4.0的特性,可以利用CPU多核的處理能力,提高運算效率,但是不一定是成倍的
LIST等泛型啟用並行計算很簡單,使用ASParallel()即可,改進如下:

? 1 2 3 4 5 6 7 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}秒\r\n", 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 Stopwatch stopWatch = new Stopwatch(); stopWatch.Start(); key = key.ToLower(); ConcurrentBag<drugInfo> resultList = new ConcurrentBag<drugInfo>(); 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}秒\r\n", eMseconds);

時間與第三步沒有什麼區別,但是這樣做解決了並發時,應用程序池假死的問題。至此,困擾兩天的問題完美解決,雖然使用Parallel.For會帶來結果亂序的問題,但是結果數量已經不多了,再次排序也沒有什麼關系了。

具體原因參見下面:

ParallelOptions.MaxDegreeOfParallelism指明一個並行循環最多可以使用多少個線程。TPL開始調度執行一個並行循環時,通常使用的是線程池中的線程,剛開始時,如果線程池中的線程很忙,那麼,可以為並行循環提供數量少一些的線程(但此數目至少為1,否則並行任務無法執行,必須阻塞等待)。等到線程池中的線程完成了一些工作,則分配給此並行循環的線程數目就可以增加,從而提升整個任務完成的速度,但最多不會超過ParallelOptions.MaxDegreeOfParallelism所指定的數目。

PLINQ的WithDegreeOfParallelism()則不一樣,它必須明確地指出需要使用多少個線程來完成工作。當PLINQ查詢執行時,會馬上分配指定數目的線程執行查詢。

之所以PLINQ不允許動態改變線程的數目,是因為許多PLINQ查詢是“級聯”的,為保證得到正確的結果,必須同步參與的多個線程。如果線程數目不定,則要實現線程同步非常困難。

有關C# PLINQ 內存列表查詢優化歷程小編就給大家介紹這麼多,希望對大家有所幫助!

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved