產品中（基於ASP.NET MVC開發）需要經常對藥品名稱及名稱拼音碼進行下拉匹配及結果查詢。為了加快查詢的速度，所以我最開始就將其加入內存中（大約有六萬五千條數據）。
下面附實體類。
public class drugInfo
{
public int drug_nameid { get; set; }
public string drug_name { get; set; }
public string drug_search_code { get; set; }
}
第一次做法：
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表達式中的轉小寫操作優化一下，先在緩存列表上做些動作，將名稱和搜索碼先轉小寫存儲。
下面為改進過的實體類。
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()即可，改進如下：
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個並發的時候，也會產生假死的情況，於是，不得不嘗試下面第四步的辦法。
---------------------------------------------------------------------------------------------------
第四次做法：
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查詢是“級聯”的，為保證得到正確的結果，必須同步參與的多個線程。如果線程數目不定，則要實現線程同步非常困難。
