(1) Select the session state storage mode
Configure in the Webconfig file:
<SessionState mode = "??? "StateConnectionString =" tcpip = FIG: 42424"
SqlConnectionString = "data source = 127.0.0.1; Trusted_Connection = yes"
Cookieless = "false" timeout = "20"/>
Asp.net can store session status information in three ways:
1. storage in the process: attribute mode = InProc
Features: it has the best performance and the fastest speed, but cannot be shared across multiple servers.
2. stored in the status server: attribute mode = "StateServer"
Feature: This method is used to maintain user session information across servers.
However, the information is stored on the Status server. Once the status server fails, the information will be lost.
3. Stored in SQL Server: attribute mode = "SqlServer"
Feature: the workload increases, but the information is not lost.
Add:
I. Because some pages do not require session status, you can disable the session Status:
The Code is as follows: <% @ Page EnableSessionState = "false" %>
II. If the page needs to access session variables but cannot be modified, you can set the page session status to read-only:
The Code is as follows: <% @ Page EnableSessionState = "false" %>
You can select a method based on the actual situation.
(2) Use Page. IsPostBack
Page. IsPostBack indicates whether it is returned from the client. Its value is not returned from the client during the first run.
It is false. When an event on the Page is triggered or the Page is refreshed, the value of Page. IsPostBack is set to true because it is sent back;
It is generally used in the Page_Load method:
Private void Page_Load (Object sender, EventArgs e)
{
If (! Page. IsPostBack)
{
...; // Initialize the Page code. These codes are executed during the first page initialization. When the second request is sent back,
// No execution will be performed. Improve efficiency.
}
}
IsPostBack is often used, because some controls need to be kept in the status after initialization.
For example, if DropDownList is initialized every time, the user will be initialized to the default value regardless of the option.
(3) Avoid using server controls
1. Do not use the Server Control to display general static display information. Because the server control needs to be sent back to the server for execution,
The program execution efficiency is reduced. Generally, <DIV> is used for display.
If the server control is used, removing runat = "server" also improves the efficiency.
2. Disable the status view of the server-side control. Some controls do not need to maintain their status. You can set its attribute to EnableViewState = false;
If the status view does not need to be maintained for the entire page control, you can set the status vision of the entire page to false:
The Code is as follows: <% @ Page EnableViewState = "false" %>
3. Configure in the Web. Config file:
ASP. NET Sessionss can be configured in the Sessionsstate element in Web. config or Machine. config.
The following is an example of setting in Web. config:
<Sessionsstate timeout = "10" cookieless = "false" mode = "Inproc"/>
(4) avoid using the DataGrid
We all know that the DataGrid is powerful. However, powerful functions increase performance overhead. Other controls are generally used: DataList
Or the Repeater control can implement, do not use the DataGrid whenever possible.
(5). String operations
1. Avoid packing. the operating efficiency of packing is relatively low.
For example, run two code segments:
String test = "";
For (for int I = 0; I <10000; I ++)
{
Test = test + I;
}
And
String test = "";
For (for int I = 0; I <10000; I ++)
{
Test = test + I. ToString ();
}
The following code segment is obviously highly efficient. Because I is an integer type, the system needs to pack and convert I to string type before connection.
You can Copy it to your machine and test it.
2. Use the StringBulider class
During string connection: string str = str1 + str2 + ....;
Generally, it is better to use StringBuilder to replace the String class. StringBuilder to avoid the re-creation of the String object.
Performance Loss.
It is generally used to assemble SQL statements: StringBulider.
You can test it on your machine. 3. Try to use less:
Try
{}
Catch
{}
Finally
{}
Statement. The execution efficiency of this statement is relatively low.
(6). ADO. Net Usage Optimization
1. Open and Close the database connection. Open the connection when you need to access the database. Close the connection immediately after the database is accessed.
For example, let's look at two code segments:
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 (); // Open the connection
For (int I = 0; I <1000; I ++) // for Loop Simulation of business logic operations before data is obtained
{
Thread. Sleep (1000 );
}
MyAdapter. Fill (ds );
For (int I = 0; I <1000; I ++) // for Loop Simulation of business logic operations after data is obtained
{
Thread. Sleep (1000 );
}
MyConnection. Close (); // Close the connection
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 Loop Simulation of business logic operations before data is obtained
{
Thread. Sleep (1000 );
}
MyConnection. Open (); // Open the connection
MyAdapter. Fill (ds );
MyConnection. Close (); // Close the connection
For (int I = 0; I <1000; I ++) /// for Loop Simulation of business logic operations after data is obtained
{
Thread. Sleep (1000 );
}
The display II code is much better than I code, and I occupies the connection early. If there are many users, the connection pool may be full. Serious crashes.
2. Database Query
I. Generate SQL statements directly. SQL Server needs to compile SQL Server every time, which won't be greatly improved in terms of performance. In addition, it is not safe enough. Easy to attack.
II. use SQL commands with parameters. In this way, SQL Server only compiles the program once. For different parameters, you can repeat the compiled command. Improved performance.
III. use SQL Server Stored Procedures. Compile once. It is independent and easy to modify and maintain. It can send Statements multiple times at a time, reducing network
Traffic. Stored procedures are not necessarily more efficient than statements. If the business logic is complex, sometimes statements are more efficient than stored procedures.
(6) Cache Optimization
There are two types of cache: Page cache and API cache.
1. Use Page cache and fragment Cache
<% @ OutputCache Duration = "5" VaryByParam = "None" %>
<% @ OutputCache Duration = 60 VaryByParam = "TextBox1, TextBox2" %>
Note: Duration sets the Cache expiration time;
VarByParam is used to set whether the parameter changes. If None is used, all parameters use the same Cache,
When TextBox1 is set, it is cached based on different TextBox1 values. When there are multiple parameters, the cache should be combined;
2. API cache. Used in applications
I. An example of Cache Usage:
Http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II. Note the differences between Page. Cache and HttpContext. Current. Cache during use:
They refer to the same object. In the Page, use Page. Cache. If you use HttpContext. Current. Cache in global. asax or your own class
In some events, HttpRuntime. Cache is used because it does not have HttpContext.
|
