(
一
).
选择会话状态存储方式
在
Webconfig
文件配置
:
<sessionState mode="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false" timeout="20"/>
Asp.net
有三种方式存储会话状态信息
:
1.
存储在进程中
:
属性
mode = InProc
特点:
具有最佳的性能,速度最快
,
但不能跨多台服务器存储共享
.
2.
存储在状态服务器中
:
属性
mode = "StateServer"
特点
:
当需要跨服务器维护用户会话信息时,使用此方法。
但是信息存储在状态服务器上,一旦状态服务器出现故障,信息将丢失
3.
存储在
Sql Server
中
:
属性
mode="SqlServer"
特点
:
工作负载会变大,但信息不会丢失
.
补充一点:
I.
由于某些页面不需要会话状态,则可以将会话状态禁用
:
代码如下:
<%@ Page EnableSessionState="false" %>
II.
如果页面需要访问会话变量但不允许修改它们,可以设置页面会话状态为只读
:
代码如下:
<%@ Page EnableSessionState="false" %>
使用时可以根据具体情况选择某种方式
(
二
).
使用
Page.IsPostBack
Page.IsPostBack
表示是否是从客户端返回的
.
初次运行时,不是从客户端返回,它的值
为
false,
当触发页面上的事件或刷新页面时,
Page.IsPostBack
由于是回发的,值变为
true;
一般在
: Page_Load
方法中用
:
private void Page_Load(Object sender,EventArgs e)
{
if(!Page.IsPostBack)
{
....; //
初始化页面的代码。这些代码第一次页面初始化时执行,当第二次回发时,
//
不会再执行。提高效率。
}
}
往往很多时候不得不用
IsPostBack,
因为有些控件初始化后,要保持它的状态
.
例如
: DropDownList,
如果每次都初始化,则用户无论选择其选项,都会被初始化为默认值
.
(
三
).
避免使用服务器控件
1.
一般的静态显示信息,尽量不要用服务端控件显示
.
因为服务端控件需要回发服务端执行
,
会降低程序执行效率
,
一般用
<DIV>
显示即可
.
如果用了服务端控件,将
: runat="server"
去掉
,
也会提高效率
.
2.
禁用服务端控件的状态视图,有些控件不需要维护其状态,可以设置其属性
: EnableViewState=false;
如果整个页面控件都不需要维持状态视图,则可以设置整个页面的状态视力为
false:
代码如下
: <%@ Page EnableViewState="false"%>
3.
在
Web.Config
文件中配置
:
ASP.NET Sessionss
可以在
Web.config
或
Machine.config
中的
Sessionsstate
元素中配置。
下面是在
Web.config
中的设置的例子:
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(
四
).
避免使用
DataGrid
大家都知道
DataGrid
功能强大。
但是功能强大的同时,增加了性能上的开销。
一般用其它控件
: DataList
或
Repeater
控件能实现的,尽量不用
DataGrid.
(
五
).
字符串操作
1.
避免装箱操作
.
装箱操作运行效率比较低
.
例如运行两个代码段
:
string test="";
for(for int i=0;i<10000;i++)
{
test = test + i;
}
和
string test="";
for(for int i=0;i<10000;i++)
{
test = test + i.ToString();
}
下面的代码段显然效率要高
.
因为
i
是整型的,系统要先把
i
进行装箱转换为
string
型的,再进行连接
.
需要时间
读者可以
Copy
到自己机器上测试一下
.
2.
使用
StringBulider
类
在进行字符串连接时
: string str = str1 + str2 + ....;
一般超过三项连接,最好用
StringBuilder
来代替
String
类
. StringBuilder
可以避免重新创建
String
对象造成
的性能损失
.
一般用于组装
Sql
语句时用到
: StringBulider.
读者可以到自己机器上测试一下
.
3.
尽量少用
:
try
{}
catch
{}
finally
{}
语句
.
此语句执行效率比较低
.
(六).ADO.Net使用方面优化
1.
数据库连接打开和关闭。
在需要连接时打开,当访问完数据库要立刻关闭连接
.
举例说明
,
还是看两个代码段
:
I.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("server=localhost; uid=sa; pwd=; database=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
MyConnection.Open(); //
打开连接
for(int i=0;i<1000;i++) //for
循环模拟取得数据前的商业逻辑操作
{
Thread.Sleep(1000);
}
myAdapter.Fill(ds);
for(int i=0;i<1000;i++) //for
循环模拟取得数据后的商业逻辑操作
{
Thread.Sleep(1000);
}
MyConnection.Close(); //
关闭连接
II.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("server=localhost; uid=sa; pwd=; database=NorthWind");
SqlCommand myCommand = new SqlCommand(strSql,MyConnection);
SqlDataAdapter myAdapter=new SqlDataAdapter(queryStr,connectionStr);
for(int i=0;i<1000;i++) //for
循环模拟取得数据前的商业逻辑操作
{
Thread.Sleep(1000);
}
MyConnection.Open(); //
打开连接
myAdapter.Fill(ds);
MyConnection.Close(); //
关闭连接
for(int i=0;i<1000;i++) ////for
循环模拟取得数据后的商业逻辑操作
{
Thread.Sleep(1000);
}
显示
II
代码比
I
代码好的多,
I
中早早占着连接不放,如果用户很多的话,容易出现连接池满情况。严重时出现死机现象
.
2.
数据库查询
I.
直接生成
SQL
语句。
Sql Server
每次都要对其进行编译,在性能方面不会有很大的提高。
另外也不够安全。容易被攻击
.
II.
使用带参数的
SQL
命令。这种方式
Sql Server
只对其编译一次,对于不同的参数可以重复使用编译后的命令。提高了性能
.
III.
使用
Sql Server
存储过程
.
编译一次
.
具有独立性,便于修改和维护
.
一次能完成用语句发送多次的功能
.
减少了网络的
流量。
并不一定存储过程一定比语句效率要高,如果商业逻辑很复杂的话,有时候用语句比存储过程效率要高
.
(
六
).
缓存优化
缓存分为两种:
页面缓存和
API
缓存
.
1.
使用页面缓存和片段缓存
<%@ OutputCache Duration="5" VaryByParam="None"%>
<%@ OutputCache Duration=60 VaryByParam=”TextBox1,TextBox2” %>
说明
: Duration
是设置
Cache
的过期时间
;
VarByParam
是设置是否根据参数而变化
,None
时所有参数使用同一
Cache,
设置
TextBox1
时则根据
TextBox1
的不同值分别缓存
;
当有多个参数时则要组合缓存
;
2.API
缓存。用于在应用程序中使用
I.
一个
Cache
使用的例子
:
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II.
使用时注意
Page.Cache
和
HttpContext.Current.Cache
区别
:
它们指的同一个对象,在
Page
里,用
Page.Cache
,如果在
global.asax
或自己的类里用
:HttpContext.Current.Cache
在有些事件中,由于其没有
HttpContext
,就用
HttpRuntime.Cache.