; html 表格格式化技术
.衡量的三种技术(不同的Data Provider )：
–传统ASP/ADO
–ASP.NET w/ System.Data.OleDb 提供商
–ASP.NET w/ System.Data.SqlClient 提供商

0
100
200
300
400
500
600
700
800
900
传统 ASP/ ADO 带 OLEDB 的
ASP.NET
带 SQL 的 ASP.NET
请求/秒（4P 服务）
数据性能测试

DataReaders 和DataSets
.DataReader
–对查询的结果提供了单向读取的操作
–轻量快速–但在Reader为关闭之前始终处于连接状态
.DataSet
–非链接的数据访问方式
–内部使用DataReader用于获取数据
–在完成DataSet的获取后会自动关闭DataReader
.如何选择?
–依赖于您的应用
–般情况下,读取大量数据,对返回数据不做大量处理用
SqlDataReader.对返回数据大量处理用datset比较合

DataReader ？DataSet
通常情况下DataReader比
DataSet快16%！！

ExecuteNonQuery和ExecuteScalar
.ExecuteNonQuery
–对数据的更新不需要返回结果集
–由于不返回结果集可省掉网络数据传输。它仅仅返回受影响
的行数。如果只需更新数据用ExecuteNonQuery性能的开销
比较小。
.ExecuteScalar
–它只返回结果集中第一行的第一列。使用ExecuteScalar 方
法从数据库中检索单个值（例如id号）。
–与使用ExecuteReader 方法，返回的数据执行生成单个值所
需的操作相比，此操作需要的代码较少
.如何选择?
–只需更新数据用ExecuteNonQuery.单个值的查询使用
ExecuteScalar

数据的绑定DataBinder
.一般的绑定方法<%#
DataBinder.Eval(Container.DataItem, “字段名”)
%>用DataBinder.eval 绑定不必关心数据来源
(Dataread或dataset)。不必关心数据的类型eval
会把这个数据对象转换为一个字符串。在底层绑
定做了很多工作，使用了反射性能。正因为使用
方便了，但却影响了数据性能。
.直接转换成DataRowView的话，将会给性能带来
很大提升：
.<@% ((DataRowView)Container.DataItem)["字
段名"] %>

连接池
.ADO.NET 拥有内置的连接池
–自动缓存/重新使用连接
–不必为此编写任何代码
.代码建议：
–“在后期打开代码中的连接，然后在早期将其
关闭”
–切勿长时间保持连接状态
–完成后应立即显示地关闭数据库连接，以将其返
回至池中

连接池
.优化提示：
–不同的连接字符串可以生成多个不同的连接池
–在Web.Config 中单个连接字符串
–使用ConfigurationSettings.AppSettings，以在运
行时采用编程形式对其进行访问
.始终应明确关闭数据连接，避免连接泄漏
–否则连接将在下一次垃圾收集之前保持打开状态
–泄露连接会显著降低性能

使用过程
.建议将SPROC 用于数据存取
–通过DBA 进行更轻松的性能调试
–通过使用数据库事务处理避免出现分布事务成本
–有助于防止SQL 注入攻击
–有助于消除应用与数据库反复调用的成本
.有趣的提示：
–可以通过企业管理器来关闭动态SQL 支持，以强制使用
SPROC

DEMO3
使用连接池优化程序

议程
.错误类型以及处理方式
.提高数据访问性能
.服务器控件的使用
.缓存的使用
.提高性能的实用技巧

服务器控件
.提供了清晰的编程模型（重用，简洁，宜用）
–创建ASP.NET 页面所倡导的模式
.对性能优化而言有两点需要注意:
–ViewState
–控件数量

ViewState 管理

. ASP.NET controls 能够维护页面Control元素的状态
– 状态以“viewstate” hidden field进行传递
. 负面影响:
– 增加网络负荷(both on render and postback)
– 额外的服务器性能消耗（serialize values to/from viewstate）
. Viewstate灵活性:
– 页面级（Can disable viewstateentirely for a page ）
– 控件级（Can disable viewstateusage on a per control basis ）
. 建议:
– 认真审核该功能的使用
– 若不使用PostBack功能