2.3 绝不建议在循环语句写如下的语句， 具体为什么,自己思考。
Foreach (DataRow row in tabl.select(“”,”ProductID”)
……………
Dim DS new Dataset 记住此乃写代码之大忌;
Dim DT new Databable….
………….
Next
还有一种写法
Dim DS new Dataset
Dim DT new Databable…
Foreach (DataRow row in tabl.select(“”,”ProductID”)
DS=GetDatase
DT=GetDatatable……………
.
………….
Next
正确的写法是：
Dim DS new Dataset
Dim DT new Databable…
Try
Foreach (DataRow row in tabl.select(“”,”ProductID”)
DS=nothing ‘每次使用，都先把内存空间释放出来
DT=nothing ‘每次使用，都先把内存空间释放出来
DS=GetDatase
DT=GetDatatable……………
.
………….
Next
Catch ex As Exception
Throw ex
Finally
DS.dispose
DT.dispose
End Try
另外，提醒大家一点，记得用 For Each 语句替代For i=0 to Rowcount-1，这样的效率改善也是明显的。
三、调试（Debug）模式下编译就用于应用环境中篇
有人会留意这个界面吗？有，但一定不多。
接着，程式开发好(也包括单元测试)，然后编译直接分发到应用环境。
整个过程就结束了。谁也不曾想，这里埋下了一个深深的地雷，据微软的人讲，这样分发的程式到应用环境，你有多少内存恐怕都不够。
所以微软建议我们做如下的工作:
“請將Web.config中的debug及Trace均設為False。還有您的所有程式請確保compile為Release Mode
Application set up for debugging
One reason for high memory that we see here in Support a lot is when you have debugging, tracing, or both enabled for your application.
While you are developing your application, this is a necessity.By default, when you create your application in Visual Studio .NET, you will see the following attribute set in your Web.config file:
<compilation … debug="true" />
and/or
<trace enabled="true" … />
Also, when you do a final build of your application, make sure that you do this in "Release" mode, not "Debug" mode. ”
如果不这样做会有什么事情发生? 我分享一个同事的感受给大家：
“已经是很强悍的的DB和AP服务器(全部是刀片式服务器)了，可是问题一而再再而三地发生，那种感觉真的很无助很凄凉啊~”
后来的结果发现是内存使用率超高，到一定限度的时候，就会反应变慢，这个时候只要重启IIS就可以好一段时间。后来分析IIS用到实体加虚拟的内存超过2G就会爆掉。
这就是原因，你想遇到吗？那就不妨试试。
四、实际操作分享篇
上面三个环节，任何一个发生问题，都会影响到系统的效率。我分享我们实际的作业的过程发生的一些情况，及怎么解决这些问题。
4.1 内存使用达到峰值，导致程序无法继续运行。
有个同事分享了他们的经验如下（原话分享）：
我们有一些程式是server跑的Job，并有越来越多之势。而大家在写程式的时候可能比较少考虑到耗内存这个问题。
下面的例子也许会给我们一点启示。
下面也是原话
Pls help to check the Run In Rack Job program . It will no response after running two or three days . the AP server Memory usage will over 2.5G . after we close the the program , Memory will decrease to 1.5 .
大致意思是：在服务器端(也叫后台)自动跑的一只程式，运行了两三天后，停止运行了。检查Server的内存使用率时,发现超过了2.5G;在关掉了这只程式后，它就降到了1.5G…
4.2 进程请求过多，导致CPU无法及时处理，程序效率反应较慢。
下面都是同事的原话:
“年后产量逐渐增加，新的问题又出现了。从Server Performance上分析，和上次Memory过高不同的是CPU使用率过高。
每当CPU过高的时候，产线会大面积的反应说慢（这点和连接到哪台AP有关系）。
每次慢的时候，我们就找到CPU过高的那台AP，recycle IIS的application pool后就OK了。
于是我么再次找到Bon帮忙分析（结论:微软结案报告 20090226V1 - SRT090119833891 Web service can't serve IISReset can fix.msg）。并给出了开发程序时的一些建议。
结论大致是说，没有进程占用了特别高的CPU，也没有进程占用CPU时间过长。只是对DB的请求的进程过多（比较吻合3厂的实际状况—附件多，刷的快），加起来就整体过高。
还发现了很多DLL是built in debug mode，这些DLL占用了过多的memory资源。
后来根据Bon的建议，我们修改了IIS application pool的设定如下，解决过多请求不能及时处理，而造成CPU过高的问题。”
这里有一些问答关于应用连接池(Application Pool)的设定，对理解这样的设置有一定的帮助:
1. Is one application pool’s maximum memory usage 1.5G?
A&: Each application pool is a w3wp.exe. w3wp.exe is a process. Every process has 2 G User mode virtual address, so the maximum memory usage for application pool is 2G. However, you can’t make sure that there is no memory fragment issue. Therefore, Out of memory always occur after 1.5 G according to our experience.
2. Is each application pool independent on memory usage?
A&: Different application pools are different w3wp.exe, so each application pool’s maximum memory usage is 2G.
3. Can setup maximum CPU usage on each application pool?
A&: You can monitor it, but you can’t setup it.
写完这篇文章的时候，我们另一项目组的开发者，也遇到了同样的问题，他们开发好的一只程式，用户反映很慢。我跑过去一看代码，完了，所有我描述的问题，他们都无一避免地出现啦，那就赶紧告诉他们，还等什么？
|