IDC资讯中心
衡量web性能的方法
l 衡量web服务器性能的唯一方式是对服务器进行压力测试（stress testing）
1. 自动压力测试工具是衡量的唯一方式
2. 浏览器的点击刷新并不能作为痕量手段……
l 收集多个典型应用场景方案：
1. 在应用车工女婿执行过程中模拟典型事物处理的过程
2. 痕量常用的单个页面的性能（热点）
3. 确定个场景及个页面的使用率
l 通过测试找出系统的新能指标：
1. 服务器的处理能力
2. 确定适合可接受ttfb/ttlb响应时间范围的可支持的最大客户端负载（并发用户）
性能测试工具
l 微软web application stress tool
1. 可免费下载（10mb），适用于xp、2000、2003
2. http://www.microsoft.com/technet/treeview/default.aspx?url=/technet/itsolutions/intranet/downloads/webstres.asp
l 微软应用程序中心测试工具（microsoft application center test）
1. 作为vs.net enterprise 的一部分提供给客户
2. 启用更丰富的脚本及报告
主要的性能测试观测项perfmon counters
l processor，cpu % utilization
low numbers = blocking or lock contention
l asp.net，requests in application queue
出现线型增长时表示服务器已达满负荷
l asp.net，applications，requests/sec
动态吞吐量（应保持一致、无大的波动）
l asp.net，applications，errors total
预示着功能级错误（应为0）
l asp.net app/worker process restarts
表示有严重错误编程级错误（应为0）
压力测试环境的注意事项
l 在独立与web服务器及应用服务器的机器上运行压力测试工具
1. 否则工具将超出服务器cpu的最大范围
2. 对于繁重的负载使用多个客户端机器
l 对测试进行配置，以模拟不同的客户端带宽级别
1. 特定用于衡量56k拨号
l 消除应用之外的任何瓶刭：
1. 网络、客户端等
逻辑设计
l 建议：采用3层逻辑模型
1. pages and user controls ui
2. business and data access classes in \bin dir
3. data withwin a sql database via sprocs
l 设计系统时要考虑到scale-out的情形
1. 不要假设客户端的请求
l 永远会返回到同一机器
使用最佳的data provider
l ado.net 可支持多个provider:
1. system.data.sqlclient
2. system.data.oracleclient
3. system.data.oledb
4. system.data.odbc
l 所有provider的编程模型相同
1. 但是性能方面存在明显差异
l 建议：使用最佳
1. 在访问msde/sql 是始终使用sqlclient
2. 在访问oracle时始终使用oracleclient
datareader vs.datasets
l datareader
1. 对查询的结果提供了单向读取的操作
2. 轻量快速-但在reader关闭之前数据库始终处于连接状态
l dataset
1. 非连接的数据访问方式
2. 内部使用datareader用户获取数据
3. 在完成dataset的获取后会自动关闭datareader
l which is better?
1. 依赖于你的应用
2. 原则上在middle_tier设计到大量数据处理或进行离线的数据访问时建议使用dataset
连接池
l ado.net拥有内置的连接迟
1. 自动缓寸/重新使用连接
2. 不必为此编写任何代码
l 代码建议
1. “在后期打开代码中的连接，然后在早期将其关闭”
2. 切无长时间保持连接状态 – 切无尝试构建你自己的“智能”连接池逻辑
3. 完成后应立即显示地关闭数据库连接，以将其返回致池中
l 优化提示：
1. 不同的连接字符串可以生成多个不同的连接池
2. 在web.config中存储单个连接字符串
3. 使用configurationsettings.appsettings以在运行时采用编程形式对其进行访问
4. 观察”.net clr数据“性能计数器，以变对由adp.net维护的连接池数量保持
使用存储过程
l 建议将sproc用于数据存取
1. 通过dba进行更轻松的性能调试
2. 通过使用数据库事务处理避免出现分布事务成本
3. 有助于防止sql注入攻击
4. 有助与消除应用与数据库反复调用的成本
服务器控件
l 对性能优化而言有两点需要注意:
1. viewstate
2. number of controls generated(especially for lists)
viewstate管理
l asp.net controls能够维护页面control元素的状态:
1. 状态以”viewstate” hidden field进行传递
l 负面影响:
1. 增加网络负荷（both on render and postback）
2. 额外的服务器性能消耗（serialize values to/from viewstate）
l viewstate灵活性:
1. 页面级（can disable viewstate entirely for a page）
2. 控件级（can disable viewstate usage on a per control basis）
l 建议
1. 认真审核该功能的使用
2. 若不使用postback功能，在页面级屏蔽viewstate
3. postback时没次都重新生成控件，请对控件级的viewstate屏蔽
4. 使用<%@ page trace=”true”%>跟踪viewstate的大小
