如今的Asp.net项目已经越来越复杂了, 在功能越来越多的时候页面打开越来越慢, 或者是一个人打开还可以, 几个人打开时就慢得不行. 本文的内容是为了解决这些问题而长时间钻研, 学习后总结出的一套方案, 涵盖了IIS优化, 缓存策略设计, ViewState优化, 局部页面缓存, 局部静态页面, 物理网络连接等方面, 希望抛砖引玉, 对各位TX有所帮助.
另外, 本文的大部分优化思路并不局限于asp.net, 所有的动态HTML技术框架应该都可以适用.
下面的内容难免有所错漏, 欢迎TX们批评指正
IIS基本优化
metabase.xml位于%WinDir%\System32\inetsrv\下的metabase.xml是IIS(本文主要争对IIS6,后同)的基础配置文件, 在这个文件中的很多选项是图形界面找不到的, 下面说些重要的属性.
MaxConnections, 这个属性其实在图形界面也可以改的, 之所以提出来是因为这个要是太小了很容易就会出现网站很慢或"连接数太多"错误.
AspRequestQueueMax, 这个属性控制Asp.net最大请求队列, 对于目标人群5000-10000人的系统来说, 设置到8192是个保险的数字, 如果太小, 系统会频繁报500错误(对小系统而言, 默认的3000已经足够).
AspSessionMax, 这个属性是控件最大的会话数, 大多数时候和上面的要求一样, 一般来说默认是不限制, 不用修改
AspProcessorThreadMax, 这个属性是很多优化文单必定要修改的属性. 作用是控制Asp.net的最大同时处理线程数, 也就是同时处理多少并发请求. 一般来讲, 设置为200左右比较理想(默认值25太小). 需要注意的是这个值不是越大越好, 太大的话, 反而会因为CPU在切换线程上消耗了大量时间而降低应用的处理效率.
AspScriptEngineCacheMax, AspScriptFileCacheSize, 这两个属性是控制.aspx, .ascx等脚本文件的编译缓存大小的, 对于有很多aspx, ascx文件的项目(比如数百个)来说, 默认的250,500显得较小, 容易经常出现重编译的现象, 影响响应时间, 建议设置成更大的数值(我都设为8192).
AspQueueConnectionTestTime, 这个值的作用是对于队列中的请求, 如果等待超过了设置的时间(秒)还没有被处理, 那么IIS会检查客户端是否还保持着连接, 如果没有, 就把这个请求移出队列.
这个功能的设计目的在于, 用户在等待页面响应的时候有一个忍耐极限, 一般而言, 超过5秒仍然没有响应的话, 就会关闭IE窗口. 这时服务器再处理这个请求的话就是白白花掉了宝贵的CPU资源. 所以设置一个合理的值是必要的, 默认是3秒, 建议设置为5秒.
还有许多比较关键的配置, 由于默认值不需要修改, 所以这里就不介绍了, 有兴趣的TX可以搜索关于IIsWebService配置节的详细信息.
启动内容超时. 这个设置在图形界面的”HTTP头”面板中设置. 建议设置为1周. 这个设置的作用在于, 像图片, css文件, 脚本文件, 静态HTML文件等这些几乎不会改变的内容, IIS会在回发给浏览器的Header中声明这个文件一周后才会过期. 这样, 我们的IE在文件没有过期的这段时间不会浪费连接和带宽来重复下载这些文件.
压缩HTTP输出
同样是在metabase.xml中, IIS6.0增加了对压缩HTTP输出的支持, 但是默认没有打开..., 启用压缩输出可以大大减少网络流量, 提高页面响应速度
在metabase.xml中查找 <IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/gzip" , 将会定位到gzip压缩输出设置节. 这个节的上面就是deflate配置节, 但是因为gzip效果更好, 所以就只配置gzip了. (注: 有些浏览器可能不支持gzip压缩的响应, 如果出现这种情况, 需要在deflate配置节下做配置而取消gzip节下的配置)
设置内容如下:
<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/gzip"
HcCompressionDll="%windir%\system32\inetsrv\gzip.d ll"
HcCreateFlags="1"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="50"
HcFileExtensions="htm
html txt js css"
HcOnDemandCompLevel="10"
HcPriority="1"
HcScriptFileExtensions="asp
dll aspx axd exe" >
</IIsCompressionScheme>
其中HcDynamicCompressionLevel是压缩率的设置, 范围是0-100, 一般适中就可以了, 太大了反而是浪费CPU资源
这样设置后, 几乎所有的HTTP输出都会被压缩了.
下一步, 查找 <IIsCompressionSchemes Location ="/LM/W3SVC/Filters/Compression/Parameters" 定位到压缩参数设置
我的设置如下:
<IIsCompressionSchemes Location ="/LM/W3SVC/Filters/Compression/Parameters"
HcCacheControlHeader="max-age=86400"
HcCompressionBufferSize="8192"
HcCompressionDirectory="%windir%\IIS Temporary Compressed Files"
HcDoDiskSpaceLimiting="FALSE"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcExpiresHeader="Wed, 01 Jan 1997 12:00:00 GMT"
HcFilesDeletedPerDiskFree="256"
HcIoBufferSize="8192"
HcMaxDiskSpaceUsage="100000000"
HcMaxQueueLength="8192"
HcMinFileSizeForComp="4096"
HcNoCompressionForHttp10="TRUE"
HcNoCompressionForProxies="TRUE"
HcNoCompressionForRange="FALSE"
HcSendCacheHeaders="FALSE"
>
</IIsCompressionSchemes>
其中HcDoDynamicCompression,HcDoStaticCompression控制是否启用动态内容压缩和静态内容压缩; HcMinFileSizeForComp指定大于多少字节的输出才会被压缩; HcMaxQueueLength类似于MaxConnections之类的配置.
注意, metabase.xml必须在IIS服务停止的情况下才能保存修改.
经过以上设置, 平均的网络流量可以节约50%-70%
compilation元素
a) debug=”false” 在运营环境, 一定要设置为false, 否则会生成无用的调试信息.
b) numRecompilesBeforeAppRestart=”15” 有时候, 我们只是改了几个页面, 却发现整个站点重新启动了, Session和Cache也已经失效, 其中一个原因就是因为重编译页面的数量超过了这里的数值. 这个值可改改高点, 不过在大部分情况下, 并不是非常有效.
c) 其它的配置项可以参考MSDN. 一般来讲默认就好.
processModel元素
这个元素就是我们在asp.net2.0下经常碰到的"莫名其秒"的丢失Session的根源了, 也是性能优化的重点之一
a) idleTimeout=”1:00:00” 当站点空闲指定的时间后将回收辅助进程(就是aspnet_wp.exe或w3wp.exe), 回收的结果就是: Session, Cache全部消失. 所以, 当内存不是很紧张的情况下, 可以设置为一个比较长的时间.
b) maxIoThreads=”20” IO操作线程的最大值, 一般来说, 我们使用WCF等远程调用, 以及数据库, 文件操作时, 都会占用IO线程. 所以, 这个数值还是高置为较大的值为好. 详细的设置见下面的"总结" .
c) maxWorkerThreads=”20” 最大工作线程数, 说白了就是同时处理的请求数, 也就是HttpApplication的实例数, 因为每个请求都会占用一个线程. 详细的设置见下面的"总结" .
d) memoryLimit=”60” 这个也是一个导致Session消失的配置, 如果辅助进程占用的内存超过这个百分比, 就会被"回收".
e) minIoThreads=”1” 这个配置的意思是至少应该保持多少个IO线程, 基本线程的创建和销毁也是比较耗时的, 这里应该设置一个较为适中的值, 比如50. 对于我们现在的服务器来说, 这点内存和切换开销还是值得的
f) minWorkerThreads=”1” 类似上面的配置, 这个是控制工作线程的, 我设置为max的一半
g) requestLimit=”Infinite” 不要修改这个配置, 不然网站又会在某个时间 "回收".
h) requestQueueLimit=”5000” 等待处理的asp.net请求队列的最大长度, 对于很忙的网站可以适当设大点.
i) responseDeadlockInterval=”00:03:00” 检查死锁的间隔时间, 如果设置的时间内有HTTP请求在排队, 而又没有一个请求返回响应, 那么系统认为发生了死锁. 虽然这个设置很有用, 但是一个健壮的网站不应该有死锁.
j) timeout=”Infinite” 不要修改这个配置, 不然网站运行配置的时间后就会 "回收"
k) 其它的配置项可以参考MSDN. 一般来讲默认就好.
httpRuntime 元素
a) 这个元素也是一个优化重点, 影响站点的整体表现
b) appRequestQueueLimit=”5000” 又是一个队列, 总之, 如果出503的话, 尝试调整一下这个配置吧
c) enableVersionHeader=”true” 控制Asp.net要不要在返回的Header中输出版本号, 在运营环境关闭可以节约少许流量.
d) minFreeThreads=”8” 最少自由线程, 自由线程在收到请求后就可以马上开始工作, 所以, 对于可能有突发的大量请求的系统, 应该设置一个较大的值
e) 其它的配置项可以参考MSDN. 一般来讲默认就好.
总结
配置项其实没有一个固定的最佳值, 关键在于调整, 测试, 再调整, 再测试…
关于线程的配置, 并不是越大越好, 因为线程越多, 切换线程的开销越大. 关于这个问题, 在MSDN上有一个线程配置的优化建议, 我们可以拿来一用. 不过, 要达到最好的效果, 自己仔细测试才是王道.
(参考
第二章: 缓存常用数据, 降低数据库请求数, 缓存策略优化.
数据库不堪重负
以我所了解的某个系统为例, 下面是它所碰到的问题:
a) 每天有2000次提交操作, 每个提交操作都是一个庞大的事务, 涉及5~10张表
b) 每天的9:00~12:30, 14:00~18:30有15000次HTTP请求, 平均每秒约0.5次, 实际上请求更加集中在11:00~12:30, 14:00~15:00之间, 在每天的这些繁忙时间, 平均每秒就有3次请求
c) 每次请求都有5~10次的数据库访问, 如果是提交请求, 访问量几乎翻倍.
d) 所以, 保守估计我们的数据库每秒处理30次请求, 其中不少还是事务操作, 虽然这样的压力对于Sql Server数据库来说并不算大, 但随着数量量与日激增, 要同时回应这30个请求的响应时间也越来越久. 举个例子来说, 我们单个请求的处理只需要0.5秒, 这个时间已经非常可以接受了, 但是现在因为同时来了30个请求, 以我们的CPU是4核心计算, 每个核心处理7个请求, 就算不计IO的累计等待时间, 每个核心也要3.5秒才能处理完, 这个时间已经超过了用户的忍耐极限.
分析这些问题, 发现因为数据量和查询复杂性的限制, 不管我们如何优化索引, 数据结构, 单个珳求响应时间的降低空间也很少了. 要解决问题, 只能减少数据库的并发访问.
用不同的数据库服务器来存储相对独立的数据是一个较好的分散请求的方式, 然而这样做意味着更大的开发难度, 而且, 这样做并不能根本解决因数据量而导致的查询缓慢.
缓存的解决方案
业界解决这一问题的做法一般是使用内存做高速缓冲, 即Cache.
asp.net常见的有内建的System.Web.Caching.Cache对象和MemCache这个开源的分布式缓存.
关于各种Cache本文就不详细解释了, 这里主要说下MemCache和Asp.net内建Cache.
MemCache的特点
a) 数据存放在专用服务器上(即可以由多台客户机共享)
b) 使用字符串作为关键字以Hash方式存储数据
c) 数据查找的复杂度固定为O(1)
d) 多缓存服务器的情况下, 通过hash来分散存储, 存储位置只与关键字有关
e) 使用socket通讯, 精简的数据协议, 效率非常高.
f) 具有故障测试, 负载分配等功能.
g) 不直接支持.net复杂类型, .net复杂类型会使用BinaryFormatter序列化
h) 支持绝对过期时间, 并且为被动过期检查(即在Get时才检查数据是否过期)
i) 其它诸如内存管理, 回收策略等这里略过不谈了, 有兴趣的TX可以Google
System.Web.Caching.Cache(以下简称Cache)的特点
a) 数据存放在本地进程地址空间中(只能由同进程的程序调用(非绝对))
b) 同样使用字符串作关键字以Hash方式存储(MSDN上没找到说明, 但印象中是)
c) 查找复杂度同样为O(1)
d) 由于是直接内存访问, 速度极快
e) 与辅助进程共存忘, 当辅助进程回收或重启时, 保存的数据消失
f) 可以设置绝对和相对过期时间, 支持过期时的回调方法(即有专门的过期检查逻辑)
g) 支持.net复杂数据类型. 缓存中只保存对数据的引用(即地址)
h) 其它特性略…
两种Cache的对比
直接讨论哪种Cache更好是没有意义的, 应该说它们各有各的适应场景
a) Memcache适合可以多客户端共享的粒度较小的数据缓存; 而Cache适合大量的, 不易改变或有明确触发条件的, 非常频繁访问的数据缓存.
b) Memcache独立的服务可靠性已经经过了许多在型门户网站的验证; 而Cache是依赖于asp.net的辅助进程, 签于asp.net的辅助进程回收机制, Cache的数据保存并不可靠.
c) Cache由于是保存的引用, 所以访问Cache中的对象不会有数据传输或Copy的开销, 适合做需要进行本地查询的对象, 如Hashtable, DataTable等. 而Memcache引用数据时将有网络传输和序列化的开销.
使用缓存的策略
现在流行的缓存策略, 一般只是把获取成本很大的数据丢到缓存中, 然后定时让它失效, 这样做逻辑简单, 有一定的效果, 但是不能做根本上解决性能的问题. 我认为理解的缓存策略应该具有如下特点:
缓存项具有明确而且可控的变更触发条件.
对于刷新成本较高的缓存项, 应该在后台刷新, 而不是在请求的时候才去刷新
缓存项应该存储尽可能完整的数据. 如整个Page, 整个UserControl的输出, 尽量减少服务的重复计算
例子:
一个Page的最原始代码:
public partial class _Default : System.Web.UI.Page
{
protected DropDownList ddl1;
protected DropDownList ddl2;
protected void Page_Load(object sender, EventArgs e)
{
ddl1.DataSource = GetData1();
ddl1.DataValueField = ddl1.DataTextField = "Text";
ddl1.DataBind();
ddl2.DataSource = GetData2();
ddl2.DataValueField = ddl1.DataTextField = "Text";
ddl2.DataBind();
}
protected KeyValuePair<string, int>[] GetData1()
{
System.Threading.Thread.Sleep(20);
var res = new KeyValuePair<string, int>[50];
for (int i = 0; i < res.Length; i++)
res
= new KeyValuePair<string, int>(i.ToString(), i);
return res;
}
protected KeyValuePair<string, int>[] GetData2()
{
System.Threading.Thread.Sleep(30);
var res = new KeyValuePair<string, int>[75];
for (int i = 0; i < res.Length; i++)
res = new KeyValuePair<string, int>(i.ToString(), i);
return res;
}
} 这个是典型的数据邦定的模式了, 这里假设GetData1需要20ms, GetData2需要30ms, 那么, 这个页面的执行时间至少要50ms, 实际上, 两个DataBind方法也会消耗不少时间, 特别是在有ItemDataBound事件处理的时候, 这个在下一章再说.
有点改进的代码:
public partial class LittleCache : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
ddl1.DataSource = GetData1();
ddl1.DataValueField = ddl1.DataTextField = "Key";
ddl1.DataBind();
ddl2.DataSource = GetData2();
ddl2.DataValueField = ddl1.DataTextField = "Key";
ddl2.DataBind();
}
protected KeyValuePair<string, int>[] GetData1()
{
if (Cache["Data1"] != null)
return Cache["Data1"] as KeyValuePair<string, int>[];
System.Threading.Thread.Sleep(200);
var res = new KeyValuePair<string, int>[50];
for (int i = 0; i < res.Length; i++)
res = new KeyValuePair<string, int>(i.ToString(), i);
Cache["Data1"] = res;
return res;
}
protected KeyValuePair<string, int>[] GetData2()
{
if (Cache["Data2"] != null)
return Cache["Data2"] as KeyValuePair<string, int>[];
System.Threading.Thread.Sleep(300);
var res = new KeyValuePair<string, int>[75];
for (int i = 0; i < res.Length; i++)
res = new KeyValuePair<string, int>(i.ToString(), i);
Cache["Data2"] = res;
return res;
}
} 很轻松的, 节约了500ms的时间, 这里需要说明的是Cache什么时候去删除呢? 答案是在Data1, Data2实际改变的时候. 具体的细节请TX们请耐心往后看
经过缓存数据的优化, 页面的响应时间和数据库的压力都已经大大降低, 但是这还只是起步而已. 对于现在的复杂需求, 一个页面经常需要邦定数十个各种各样的下拉框, 选择框, 表格等等控件, 就算数据获取不要时间, 整个页面执行下来也已经慢得不行了.
这里面当然有asp.net本身作为中间语言的执行效率问题, 也有Windows操作系统一直以来的并发效率问题, 但是, 有些东西我们是无法改变的, 我们能改变只有我们的代码. 所以, 下一章将说说如何降低我们的IIS和Asp.net程序的响应时间.
第三章: 页面结构优化, 使用页面缓存和局部页面缓存, 延迟加载
引言
上面的两章介绍了IIS的优化和一些基本的数据缓存, 这些优化是基本的和广泛的, 需要的工作时间也很少, 但是就效果来说, 完全不是这一单所说内容的对手了.
本章的优化需要细致的分析网站业务, 花较多的时候调试和测试. 但是, 回报也是相当丰厚的, 优化得当, 响应时间就会像08股市一样.
页面结构优化
页面结构优化在门户网站中已经提出很多年了, Yahoo的13条”军规”也已经深入人心, 但是, 光有这些还是不够的, 下面就说说自己的一些经验. 其中也包括某些”军规”的内容, 关于HTML文件的结构就不用说了, 这里主要引述军规中的一些经验
css文件应该放在<head>中, 这样页面刚显示出来的时候就已经如我们所想的一样呈现了; 否则, 可能用户会看到页面中的元素像游泳一样在窗口中游荡. 字体匆大匆小.
css文件尽可能的少, 并且内容尽可能的精简.
原因: 浏览器在下载页面的数据时, 一旦遇到css文件, 将立即解析这个文件的内容, 然后再往下解析其它的数据. 所以, css文件的内容大多, 将会影响页面的解析速度.
另一方面, 如果css文件个数太多, IE会不断的请求-下载-解析-请求-下载-解析……虽然这个影响非常的小, 但是当我们的网站流量或CPU紧张的时候, 优势就体现出来了.
js文件同样尽可能少, 同样应该精简, 同时, js文件的引用尽可能的放在页面的呈现内容之后. 因为IE对js文件也是会完全解析之后再往下解析的(加了defer的除外). 放在后面可以让用户先看到内容. 如果必须放在前面, 要尽量精简.
图片尽可能少和小, 原理同上. “军规”中推荐的方法是用一个大背景图, 使用style和<map>来利用这个图的不同部分做背景或是链接.
其实要用一个大背景拼一个页面并不容易. 当我们的网页本身比较简洁的时候是不需要这样搞的, 只要尽可能的减少网页引用的文件数量就行了. 实际上这个优化项也是减少请求-下载-解析的时间浪费.
启用”内容过期”的Header, 方法和原理在第一章已经讲了, 这样可以明显减少网页使用的网络流量, 减少页面的呈现时间.
启用HTTP输出的压缩, 这个可能放在这里不是合适, 但是第一章的这些内容是很重要的, 还是要强调一下, 一半以上的流量节约是很诱人的.
尽量禁用ViewState, 这个是老话题了, 一方面ViewState可以说是对网络带宽的浪费, 另一方面解析ViewState也是一个耗时的过程.
对于不得不用的ViewState, 可以重载Page的PageStatePersister属性, 返回SessionPageStatePersister的实例. 这样可以把ViewState存在Session中(2.0才有的方法, 另外注意Session是易失的). 对于大部分的应用已经是够用了.
最后, 文件的结构尽量简单, 一个页面尽量控制在100K以内, 因为太大的页面即使下载很快, IE解析它也会消耗很多的时间, 带来的问题就是用户很长的时间内只看到一个白页或是只看到页面的一部分.
接着上面的内容, 如果内容确实较多, 尝试把某些不是必须立即呈现的内容"折叠"起来. 在用户点击某个按钮才展现出来(展现的过程是需要使ajax或类似的方式, 如果只是style.display=’none’用户不大).
尽量不在页面上或脚本中定义字数非常多而且带有转义字符(如\,<>,[]之类)的字符串, 特别是在脚本或是标签元素的属性上. 某些浏览器(如果我遇到过IE6)在解析这类元素时可能意外的耗时.
延迟加载部分内容
当页面的内容已经不能再精简但还是超过100K很远, 而用户又希望直接能看到全部内容时, 应该考虑延迟加载某些内容了. 所谓延迟加载就是一开始不处理某些内容, 然后由页面自动回发一个请求来加载这些内容. 这样用户既很快的看到了基本内容, 又可以在可以接受的时间内看到全部的内容.
延迟加载有很多方式, 上面提到的"折叠"方式就是一个, 只不过是用脚本来按一下那个按钮. 下面介绍下使用UpdatePanel的方式来延迟加载
原文地址:http://bestshuai.spaces.live.com ... C7F270A5D!354.entry
