1 前言
性能优化的主要目标是提高“并发用户数量”，“吞吐量”，“可靠性”这样几个指标。
本质上说，性能优化的工作应该是多方面的，要做到“点面结合、由表及里”。比如：从代价的角度来考虑，应尽量做到改动量小，易实施；从用户角度看，应做到快速响应或快速提示；从软件结构的角度看，又要兼顾到系统结构的合理性和可扩展性。由此不难发现，在尝试一些改进方法时往往很难做到面面俱到。
举一个简单的例子：
在一个业务逻辑类中，我们封装了一些处理方法，其中有一个方法的功能是查找一个节点ID在XML文件是否已经存在。那我们自然会想到写两个方法：
XmlDocument LoadXML(string strFileID) //加载XML
bool CheckIDExisit(string strFileID,string strID) //判断节点是否存在
而且，加载XML的方法在其他地方还可以重用；表面上看，这段代码的结构和功能都没有问题。可是在运行时，如果你的逻辑中直接或间接调用了LoadXML多次的话，你会发现程序很慢。原因就在于加载XML文件是个耗时动作，解决的方法很简单，我们再提供几个方法即可：
bool CheckIDExisitByXml (string strXml,string strID) //判断节点是否存在
或 bool CheckIDExisitByXml (XmlDocument objXml,string strID) //判断节点是否存在
这样，我们就可以通过“一次加载”实现多次借用，效率明显提升。所以，在软件结构设计时就应将可重用“珍贵”数据源的因素考虑进来。(这里的“珍贵”数据源是指那些经过复杂处理或长时间计算才得到的各种对象或记录集)。
性能优化的工作又应是长期的，因为我们的工作始终是建立在OS,Web Server, DB Server, Complier & Program Language等等的基础上的。如果你熟悉.NET, JAVA,IIS, J2EE, 你就会发现有些功能或API这个平台提供了，另一个却没有；所以更多时候我们需要过渡的解决方案，等到新版本出来时，我们可能就会抛弃过渡方案直接配置或更简便的实现一些功能。[...]
2 需求篇
性能优化的第一步是看看需求是否合理，这是对项目本身的一次回检。某种意义上说，是一种逃避原则。但如果从软件工程的角度来说这是必须的，因为客户的需求是无止境的，而任何软件都是有生命期的，OS都是这样何况应用软件。我们总是希望用户显示与业务逻辑分开的越远越好，却忽略了一个基本问题：两者终归要衔接起来，如何定义两者之间的I/O关系，让它们能有效的相互配合并最终让用户满意是非常重要的。
所以，在性能优化时回检需求就是要把用户交互定义好，使之更科学化。从业界发展动态看，现在已经有专门的人在研究用户交互，这就像传统行业里的所谓“工业设计”一样，正越来越被重视！
在回检需求时往往会“修改需求”，这时应该结合“需求定义人员”和“开发人员”两方面的意见，因为各方角度不同，一定要取长补短。
3 交互响应篇
前面提到性能优化时可按“由表及里”的顺序，这主要有两方面的考虑：
第一， 这是用户直接看到的东西，见效快；
第二， 改动难度比改动内核要小。
基于B/S结构的应用程序有前台(用户)与后台(Server)交互的问题，所以交互响应过程实际包括“后台计算”与“加载到客户端”两个过程。那么很显然，我们如果尽量减少需要下载到客户端的数据量，会减小响应时间。
根据测试，我们发现将4万条记录绑定到Grid的时间在35s左右，而实际上我们不会在页面一下子显示这么多条记录，用户也不可能一下子浏览这么多记录。通常我们使用分页的方式，而所谓的分页只不过是重新绑定一下数据。所以，如果如果我们每次只绑定所请求的那一页则到客户端的数据量会陡降。这就是我们提出的“计算全部数据，加载局部数据”的思路（如下图）。
图 3-1 “即时按页绑定”原理图
我们再从用户的角度看另外两个问题，曾使用ASP应用程序的人会发现ASP.NET应用程序使用时刷新频率很高，一个小小的动作都要提交到服务端去处理。从软件设计的角度看，我们觉得很合理，因为没有耦合且逻辑可重用。可是“鱼与熊掌不可兼得”，我们还是应该采取折中的手法。回到我们的系统中来，我们发现多数页面在对于使用较频繁的“增-删-改”操作时，都是每一次操作都从数据库重新读，重新绑定。如此频繁的刷新，用户不会很认可，同时如果数据量大也会影响交互时间。
实际上，如果数据是显示在Grid中，那么删除和修改时根本不需要重新Load, 直接用控件本身的方法就可以了，虽然也会提交但与重新绑定还是有明显区别的，速度也快得多！对于TreeView则“增-删-改”都不需要重新Load，因为它不需要分页。
另一个问题是对于复杂并可能耗时的计算过程，用户虽可理解，但还是应该给出提示或进度条。这并不属于性能优化的范畴，但却是重要的UI规范，建议纳入测试要求。关于进度条的显示有两种方式：
1 前台显示等待或完成进度，后台处理完了，前台进度条关闭，处理结果显示；
2 提交任务到后台后，转到一个等待页面，等后台完成后转到确认页面。这种方式通常基于XmlHttpRequest[13]技术，在后台创建单独的计算线程，其优点是可以避免后台过于繁忙导致第一种显示方式中客户端长时间没有反映，连进度条都不动了。
4 部署篇
部署其实是一个很大的概念，涵盖了软件和硬件。这里我们暂将系统部署结构、软件设置、硬件配置都纳为部署范围。关于怎样去部署一个软件系统这里就不赘述了，仅将一些具体做法列举出来。
在有大数据量传输时，经常会遇到“out of memory”的异常。这时可调节machine.config文件中processModel子项中的memoryLimit 属性的值，使得.NET可以利用更多的内存。
4.2 其他
4.2.1 优化配置Server & IIS
4.2.1 .1扩大IIS高速缓存
|
服务器保留了一部分内存空间用作IIS高速缓存，为将来的请求存储对象，这样IIS就可从高速缓存中检索对象而不用从硬盘中检索。调整IIS高速缓存的容量需要修改注册表，表项如下： HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\MemoryCacheSize =0x 1E84800（类型为REG_DWORD，using hexadecimal notation.） 也可设为十进制，范围0-4GB,缺省值为3072000（3MB）。一般来说此值最小应设为服务器内存的10%。 IIS通过高速缓存系统句柄、目录列表以及其他常用数据的值来提高系统的性能。这个参数指明了分配给高速缓存的内存大小。如果该值为0，那就意味着“不进行任何高速缓存”。在这种情况下系统的性能可能会降低。如果你的服务器网络通讯繁忙，并且有足够的内存空间，可以考虑增大该值。必须注意的是修改注册表后，需要重新启动才能使新值生效。 |
4.2.1 .2调整IIS占用CPU时间
|
服务器的CPU处理器能力总是有限的。哪一个应用程序占用处理器的时间最长，谁的性能就能得到最大的提高。 |
4.2.1 .3协议及相关优化
|
（1）为了提高性能和节约资源，应该只运行需要的协议。 |
4.2.1 .4 调整失效时间
|
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ObjectCacheTTL=0x8CA0. |
4.2.1 .5 调整最大线程数
|
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\w3SVC\ASP\Parameters，增加ProcessorThreadMax，减小这个值，看看性能的变化；或者增大这个值。) |
4.2.1 .6 注册表中的其他可优化项
|
以“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\”为父节点； |
|
CacheSecurityDescriptor Indicates whether security descriptors are cached for file objects. A value of 1 enables this feature. A value of 0 disables this feature. When enabled (the default setting), security descriptors for files are saved when caching a file object. As long as the file is cached, IIS will not need to re-access the file to determine access rights for new users. This value is most useful for sites that authenticate users and not useful for sites that allow anonymous access. |
|
CheckCertRevocation Indicates whether IIS checks to see if a client certificate is revoked. If you issue your own certificates and make local certificate checks, you might want to enable this feature. Otherwise, the feature should be disabled, which is the default. A value of 1 enables this feature. |
|
DisableMemoryCache Indicates whether IIS memory caching is enabled or disabled. By default, memory caching is enabled (meaning this value is set to 0). Disable memory caching only for testing or development purposes. |
|
ListenBackLog Specifies the maximum number of active connections that IIS maintains in the connection queue. The default value is 15 and the range of acceptable values is from 1 to 250. |
|
MaxCachedFileSize Determines the maximum size of a file that can be placed in the file cache. IIS will not cache files that are larger than this value. The default value is 262,144 bytes (256 KB). |
|
MaxConcurrency Specifies how many threads per processor should be allowed to run simultaneously if there is a pending input/output (I/O) operation. The default value (0) allows IIS to control the number of threads per processor. You can also set a specific value. |
|
MaxPoolThreads Sets the number of pool threads to create per processor. Each pool thread watches for a network request for a CGI application and processes it. This value does not control threads that are used by ISAPI applications. By default, the value is set to 4. On a single processor system, this means that only four CGI applications could run simultaneously. |
|
MemCacheSize Sets the maximum amount of memory that IIS will use for its file cache. If IIS does not need this much memory, it will be left for other applications to use. By default, IIS uses 50 percent of the available memory. The valid range is from 0 megabytes to the total amount of physical memory available in megabytes. |
|
ObjectCacheTTL Sets the length of time (in milliseconds) that objects are held in memory. If the object hasn't been used in this interval, it is removed from memory. The default value is 30 seconds (300,000 milliseconds). |
|
PoolThreadLimit Sets the maximum number of pool threads that can be created on the server. This limit is for all IIS threads. The default value is twice the size of physical memory in megabytes. |
4.2.1 .7禁用不必要的服务:
|
禁用专用 Web 服务器不需要的 Windows 2000 服务。方法是：单击开始，依次指向程序、管理工具，然后单击计算机管理。在“计算机管理（本地）”下，展开“服务和应用程序”，然后单击服务。当前所运行服务的状态 列中显示已启动 。以下服务是专用 Web 服务器上不需要的： 警报器 |
4.2.1 .8 最大化网络应用程序数据吞吐量
|
在工作内存中运行IIS 5.0 进程可分页代码。方法是： |
4.2.1 .9优化后台服务的性能
|
IIS 5.0 进程 (Inetinfo.exe) 作为后台服务运行。要提高后台服务的性能，请按以下步骤操作： |
4.2.1 .10 最小化 IIS 5.0 日志记录
|
禁止对不需要的 Web 站点、虚拟目录或文件及文件夹进行日志记录。方法是： |
4.2.1 .11启用带宽限制
|
限制各 Web 站点可用的网络带宽。方法是： |
4.2.1 .12 限制处理器使用
|
限制 Web 站点对处理器的占用量。方法是： |
4.2.1 .13限制 Web 站点连接
|
限制各 Web 站点可用的连接数量。方法是： |
4. 2.1.14 使用“保持 HTTP 连接”
|
默认情况下，能够使用“保持 HTTP 连接”。要验证是否启用了“保持 HTTP 连接”，请按以下步骤操作： |
4.2.2 优化配置DBServer
4.2.2 .1 SQLServer
|
内存是影响Microsoft SQL Server系统性能的一个重要因素。 SQL Server数据库安装时将为具有32MB物理内存的机器缺省配置16MB可用内存，16MB物理内存的机器缺省配置4MB可用内存。应在Microsoft SQL Server数据库安装后进行内存选项(Memory)设置。为了确定SQL Server系统最适宜的内存需求，可以从总的物理内存中减去Windows 2000 Server需要的内存以及其它一些内存需求后综合确定。 合理扩充虚拟内存、增大SQL Server可用内存 使用tempinRAM |
4.2.3 硬件提升
4.2.3 .1 CPU/内存
|
如果测试确定存在处理器问题，您的第一个选择当然就是将处理器升级或切换到多处理器计算机。如果确定要升级处理器，应确保它有最大的 L2 缓存，IIS 将因此而受益，因为它的许多指令路径都包括多个组件，它们在高速缓存中运行时速度会大大加快。 计算机名\内存\可用内存 - 该计数器跟踪系统中的可用内存总量。操作系统尝试将该值保持在 4 MB 以上。为了达到最佳性能，该值最好为内存总量的 5%。 |
4.2.3 .2 硬盘
|
不要将日志文件与 Web 页存储在同一个硬盘上。这将阻止硬盘日志记录线程干预检索 Web 页的线程。 优化 Web 页存储。站点上的所有相关 Web 页应该存储在同一个逻辑分区，这样可以提高文件系统缓存的性能。同时，Web 页文件不应有任何碎片，这样可以极大地加快读取单个文件的速度。 如果使用Ultra2的SCSI硬盘，可以显著提高IIS的性能。网络接口卡，内存的升级自然不用多言。 |
5 Session管理篇
HTTP 协议之所以能够获得如此大的成功，其设计实现的简洁性和无状态连接的高效率是很重要的原因。而为了在无状态的 HTTP 请求和有状态的客户端操作之间达到平衡，产生了服务器端会话 (Session) 的概念。Session的引入极大地方便了Web编程，但与之对应的Session管理变得异常重要。目前ASP.NET可以通过“进程内”、“进程外专用状态管理服务”和“SQL Server状态服务管理”三种方式来进行状态管理。对于默认的“进程内”管理方式只实现了一个进程内的基于内存的状态管理，故而存在很多问题：
1.所有的 Session 数据都保存在 Web 服务的进程中，会造成服务器支持会话数量受到服务器内存资源的限制问题，同时也因为大量非活动会话导致内存被无效占用。
2.服务器进程崩溃会导致所有的会话数据丢失。
回到我们的实际系统，目前我们使用Session变量大致有四种用途：
图5-1 Session变量使用范围
显然，前三种方式都是小数据量的，我们这里主要关注第四种方式——Session数据集变量。
把整个数据集存放在Session中，主要是为了用于后续处理或二次加工或用户翻页时重新绑定，一般情况下我们在编码时会忽略数据集的大小给Web-Server和交互时间带来的影响。实际上，一个超大数据集(记录数在10万条以上)所占用的空间是相当可观的，如果有数个并发，Web-Server的内存会急剧紧张。下表是实际测试的关于SQL执行时间的统计。
|
记录数（万） |
执行时间（秒） |
|
10 |
4 |
|
11 |
6 |
|
15 |
10 |
|
20 |
11 |
|
30 |
12 |
|
40 |
16 |
|
50 |
19 |
表 5-1 数据查询执行时间统计表
有一种解决方法是将复杂查询的“查询条件”存于Session中。这种方法简洁又轻便，但是也会造成“由于频繁查询导致db-server繁忙”的局面(50万条记录的查询时间大于15s)；理想的解决办法是实现在数据库查询时可进行分页或者说可以按页查询，这时Session中完全可只存放查询条件，因为交互数据量也不大。Oracle和SQLServer2005中可以比较方便地实现此功能，但SQLServer2000中实现起来比较麻烦，一般都会用存储过程。
考虑到已有系统在实现上并没有考虑大数据量而且也不是每个页面或逻辑都会出现大数据量，所以不应该采用单一的Session管理方案。实际上，我们可以构造具有自适应性的数据访问执行器和Session管理器，动态地去按不同的方式返回和存储执行结果。由于目前系统的Session管理模式为“进程内”(INPROC)模式且由于IIS没有提供平滑的可配置二级（内存/硬盘）缓存介质切换 ，所以可自行构造虚拟存储空间，缓解并发压力。下面是该方案的总体结构图：
图5-2 全局Session管理结构图
首先，我们来看一下数据访问执行的流程图（图5-3）。
由图5-3可知，我们在执行查询时会设定一个时间阀值，如果在规定时间内执行完毕说明数据量不是很大那么直接将结果集返回给前台；如果超时了，则会返回一个小数据集(比如 Top 1000)，然后在后台另辟线程继续查询动作并将最终结果集保存到Session，注意这时的数据集在一般情形下是很大的但也可能由于服务器繁忙造成等待，所以我们会通过Session Manager去动态按适合的方式保存。
图5-3 数据访问执行器流程图
下面是SessionManager类结构的简单示意图，
图 5-4 PageSessionManager类结构简单示意图
必须说明这只是一个简单示意图，在具体实现时这个结构会大大丰富。比如，要加上当前Session的保存方式和保存数量等。实现PageSessionManager的目的是为了规范Session的使用尤其是Session数据集变量的使用，我们会根据数据集的大小来自动选择存储方式，下面是存储Session数据集变量的流程图。
图 5-5 保存数据集变量流程图
可以看到，我们在SessionManager中引入了一种新的存储方式——虚拟存储(Virtual Store)。其目的显然是为了缓解Web-Server内存压力，提高并发度。经检测，这种方式还是比较快的；如果把XML保存到数据库，则在获取XML或读取XML时会发生超时异常。实际上，我们是自行构造了一种进程外Session管理器，那么也自然需要进行Session的清除和失效管理，我们可以在后台运行专门的失效管理进程，具体实现方法可参考下图。
图 5-6 虚拟存储示意图
另一个问题是虚拟存储文件与Http进程的对应关系如何建立。这并不难，我们只要创建一个GUID存放在同名的实际Session中，虚拟Session的文件名以此GUID为标识即可。
与存储相对应的，在通过SessionManager获取Session值的时候，SessionManager也要自动根据当前存储方式反馈相应结果，其实现过程并不复杂，这里就不赘述了。
总的来说，这套解决方案的特点是提高并发度和保证快速响应，但对某些问题的处理也有不便。比如，查询需要二次加工的记录集时希望一次得到全部数据集(即使很大)，这时必须设定相应属性值告诉AdaptiveExecutor，使之按照指定方式执行；还有就是大数据量时，分页控件在查询结束时不能瞬时得到总页数。
6 代码篇
这里的代码级优化是指对具体的代码实现特别是某个业务逻辑的算法的改进。在前言中举的一个例子就属于代码优化。代码优化是深层次的，需要非常熟悉业务逻辑和数据流，所以难度也是最大的。但在除去业务逻辑之后，我们还是可以对编码技巧或者算法结构达成共识的。本篇主要列举一些实际编码过程中基于性能考虑应当掌握的方法和注意点。
• 不要使用不必要的Session，和ASP中一样，在不必要的时候不要使用Session
• 不使用不必要的Server Control
• 不使用不必要的ViewState
• 不要用Exception控制程序流程
• 禁用VB和Jscript动态数据类型
• 使用存储过程完成数据访问
• 只读数据访问不要使用DataSet
• 关闭ASP.NET的Debug模式
• 使用ASP.Net Output Cache缓冲数据
• 尽量用SQL返回DataGrid需要绑定的DataSet,尽量不要对DataSet进行二次加工，特别不要对DataSet进行大量删除，实践证明这很慢。不如复制部分数据。
• 尽量不要对DataSet二次加工或者在通过DataSet拼成对象集；显然，若有40000条记录就意味着要拼>=40000次的对象
• 尽量把查询数据的数据库操作次数压缩到最少，尽量1-2次数据库操作就可完成；如果对查询得到的DataSet的每项数据再进行查询，那么意味着如果有40000条记录，至少要执行400001次数据库操作，加上遍历DataSet、生成对象的时间，是相当惊人的
• 注意优化数据库查询操作，比如无条件查询时不要通过离散值一个一个取；
• 注意限制大数据量查询操作，比如预计一个页面如果一个条件都不加会出现很多数据，则强制至少加一个查询条件；
• 不要在页面加载时默认选择全部数据，尽管可以方便后续操作，但用户会以为“还没有操作就这么慢”
• 建议尽量用比较高效的SQL代替后续复杂的DataSet二次加工
• 仅在需要的时候打开数据库连接
• 一旦数据库操作完毕，一定关闭连接
• 在关闭连接时记得删除临时对象
• 在关闭连接前，确保关闭任何用户定义事务
• 若要利用连接池，不要使用应用角色(application roles)
• 显示非交互性数据，使用SQLDataReader可以获得最佳性能
• 通过在SQL中得到html码比用DataGrid Component格式化数据显示具有更好的性能
• 一般而言，在循环中使用索引(index)比使用集合(collection)具有更好的性能。因为CLR (Common Language Runtime)有时可以根据数据索引进行优化，而集合则不然
• 注意共享那些经过复杂处理或漫长查询才得到的数据
• 在页面跳转时记得终止当前页面的处理
• 如果页面加载或后台计算中有一些数据不相关的处理逻辑，可以考虑采用多线程；页面加载也可以考虑逐步加载(Response.Flush())
• 有大量连接的字符串操作不要使用+，改用StringBuilder
7 Reference
2. http://www0.ccidnet.com/tech/web/2001/09/28/58_3369.html
4. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp
5. http://www.microsoft.com/china/technet/itsolutions/net/maintain/netopsgd.asp
6. http://www.programfan.com/showarticle.asp?id=2548
7. http://www.microsoft.com/china/msdn/library/webservices/asp.net/CachingNT2.mspx
8. http://www.programfan.com/showarticle.asp?id=2548
9. http://www.microsoft.com/china/msdn/library/webservices/asp.net/CachingNT2.mspx
10. http://www.SQL-server-performance.com/asp_net_performance.asp
11. http://www.cnblogs.com/flier/archive/2004/08.html
12. http://soft.yesky.com/SoftChannel/72342380468043776/20050223/1914105.shtml
13. http://jibbering.com/2002/4/httprequest.html