同样，我们多刷新页面几次，获得的平均时间为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}秒rn", eMseconds);
时间与第三步没有什么区别，但是这样做解决了并发时，应用程序池假死的问题。至此，困扰两天的问题完美解决，虽然使用Parallel.For会带来结果乱序的问题，但是结果数量已经不多了，再次排序也没有什么关系了。
具体原因参见下面：
ParallelOptions.MaxDegreeOfParallelism指明一个并行循环最多可以使用多少个线程。TPL开始调度执行一个并行循环时，通常使用的是线程池中的线程，刚开始时,如果线程池中的线程很忙,那么,可以为并行循环提供数量少一些的线程（但此数目至少为1，否则并行任务无法执行，必须阻塞等待）。等到线程池中的线程完成了一些工作,则分配给此并行循环的线程数目就可以增加，从而提升整个任务完成的速度，但最多不会超过ParallelOptions.MaxDegreeOfParallelism所指定的数目。
