Author: rob Howard
From: http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/default.aspx
Translation: chyich
Time:
This article discusses:
? The myth of improving the performance of Asp.net applications
? Useful skills for improving the performance of Asp.net applications
? Asp.net application database operations suggestions
? Cache and background processing processes in Asp.net
Writing an Asp.net web application becomes very simple, and many programmers do not want to take the time to build an application with good performance. This article will discuss the Top Ten ways to improve the performance of Web applications. I will not limited to only discussing the content of Asp.net applications, because they are only a subset of Web applications. This article does not provide a complete guide to improving the performance of Web applications, because it requires a book. This article only provides a good start to improve the performance of Web applications. (The only thing we can do is to study it slowly ).
Outside of work, I often go to rock climbing. Before each rock climbing, I will review the rock climbing route diagram and the suggestions of the successful climbers. Because we need their successful experiences. Similarly, when you need to modify a program with performance problems or develop a high-performance website, you also need to learn how to write a high-performance web application.
My personal experience mainly comes from working as a program manager in Microsoft's Asp.net group, running and managing www.asp.net website, and assisting in the development of Community Server (it is Asp.net forums ,. text, and ngallery integrated upgrade software ). I think these experiences can help you.
You may think of dividing your application into different logic layers. You may have heard of a layer-3 physical architecture or a layer-N architecture. This is the most common architecture mode. It assigns different program functions to various hardware for execution. In this way, if we want to improve the performance of the application, we can add some hardware. This method can improve application performance, but we should avoid this method. Therefore, whenever possible, we should put the Asp.net page and the components it uses into an application for running.
Because distributed deployment requires Web services or remoting, it will reduce application performance by 20% or more.
The data layer is a little different. It is best to deploy it independently and run it with a separate hardware. Even so, the database is still the bottleneck of application performance. Therefore, when you want to optimize your program, you should first consider optimizing the data layer.
Before modifying the performance issue of an application, you must first confirm that the program looks tight where the problem occurs. The performance analyzer is very useful for finding out where the application took a long time. We don't feel these places intuitively.
This article discusses two types of performance optimization: Big optimizations, such as Asp.net cache and tiny optimizations ). Small performance optimizations are sometimes very useful. You only Code Make a small change, and then call it one thousand or 10 thousand times at a time. For a large performance optimization, your application speed will be greatly improved. For a small performance optimization, each request may only increase by one microsecond. However, if the number of requests per day is large, the application performance will be significantly improved.
Data Layer Performance
When you want to optimize the performance of an application, you can work in the following order: Do your code need to access the database? What is the frequency of accessing the database? Similarly, this test method can also be used in program code using web services or remoting. This article will not discuss the optimization of programs using Web Services and remoting.
If there is a request in your code that must access the database, and you can see code that implements the same function elsewhere, you must first optimize it. Modify and complete the test. Unless you have a very high performance problem, you 'd better spend your time optimizing the query, connecting to the database, and returning the dataset size, and the time for a query to return.
Based on the experience, let's take a look at the ten experiences that can help you improve the performance of your applications. I will explain them in sequence based on the increase in efficiency.
1. Multiple datasets are returned.
Check your database access code to check whether there are multiple requests to be returned. Each round-trip reduces the number of times your application can respond to requests per second. By returning multiple result sets in a single database request, you can reduce the communication time with the database, make your system scalable, and reduce the workload of the database server to respond to requests.
If you use dynamic SQL statements to return multiple datasets, we recommend that you use stored procedures instead of dynamic SQL statements. Whether to write the business logic to the stored procedure is a bit controversial. However, in my opinion, writing business logic to a stored procedure can limit the size of the returned result set, reduce the traffic of network data, and do not need to filter data at the logic layer. This is a good thing.
Use the executereader method of the sqlcommand object to return a strong business object, and then call the nextresult method to move the dataset pointer to locate the dataset. Example 1 shows an example of returning multiple arraylist strongly typed objects. Only returning the data you need from the database can greatly reduce the memory consumed by your server.
Ii. Paging data
ASP. Net DataGrid has a very useful function: paging. If the DataGrid allows paging, it only downloads data on a certain page at a certain time. In addition, it has a data paging navigation bar, which allows you to choose to browse a certain page, in addition, only one page of data is downloaded at a time.
But it has a small drawback: You must bind all the data to the DataGrid. That is to say, your data layer must return all the data, and the DataGrid then filters out the data needed for the current page based on the current page. If there is a result set with 10 thousand records to be paged using the DataGrid, assuming that only 25 data entries are displayed on each page of the DataGrid, it means that 9975 data entries are discarded in each request. Each request must return such a large dataset, which has a very high impact on the performance of the application.
A good solution is to write a paging stored procedure. Example 2 is a paging Stored Procedure for the orders table of the northwind database. You only need to pass the current page number. Each page displays two parameters. The stored procedure will return the corresponding results.
On the server side, I specifically wrote a paging control to process data pages. Here, I used the first method and returned two result sets in a stored procedure: total number of data records and Required result sets.
The total number of records returned depends on the query to be executed. For example, a where condition can limit the size of the returned result set. Because the total number of pages must be calculated based on the dataset record size on the page, the number of records in the result set must be returned. For example, if there are a total of 1000000 records, you can use the where condition to filter and return only 1000 records. The paging logic of the stored procedure should know the data to be displayed.
Iii. Connection Pool
Using TCP to connect your applications to the database is expensive (time-consuming). Microsoft developers can use the connection pool to repeatedly use the database connection. A TCP connection is created only when no valid connection exists in the connection pool. When a connection is closed, it will be put into the pool, and it will still maintain the connection with the database, which can reduce the number of TCP connections to the database.
Of course, you should pay attention to the connections that you forget to close. You should close them immediately after each connection is used up. I want to emphasize that no matter what people say. the GC (Garbage Collector) in the. NET Framework will call the close or dispose method of the connection object after you use up the connection object to explicitly close your connection. Do not expect the CLR to close the connection within the expected time. Although the CLR will eventually destroy the object and close the EDGE connection, we cannot determine when it will actually do these things.
To optimize the connection pool, there are two rules. First, open the connection, process the data, and then close the connection. If you have to open or close the connection multiple times in each request, this is better than always opening an EDGE connection, and then passing it to each method. Second, use the same connection string (or use the same user ID when you use integrated authentication ). If you do not use the same connection string, for example, you use a connection string based on the login user, this will not take advantage of the connection pool optimization function. If you use the integration argument, you cannot make full use of the optimization function of the connection pool because there are many users .. Net CLR provides a data performance counter, which is very useful when we need to track program performance characteristics, including connection pool tracking.
No matter when your application will be connected to resources on another machine, such as databases, you should focus on optimizing the time spent on resource connection, receiving and sending data, and the number of rounds. Optimize every process hop in your application. It is the starting point to improve the performance of your application.
The Application Layer connects to the data layer, transmits data to the corresponding class instance, and the business processing logic. For example, in Community Server, You need to assemble a forums or threads set and then apply the business logic, such as authorization. More importantly, you need to complete the cache logic here.
The translation has not been completed. continue next week.
Source: http://blog.aspcool.com/chyich/
|
