10 points of attention for writing high-performance Web applications

Article discussion:

1. General ASP.net performance points

2. ASP. Useful performance points and tips in net

3. ASP. Some suggestions for using database in net

4. ASP. Cache and background processing in net

content:

Data-tier performance

TIP1: Returning multiple result sets

TIP2: Data Access Paging

TIP3: Connection Pool

Tip4:asp. NET Cache API

TIP5: Pre-Request caching

TIP6: Background processing

TIP7: Page output caching and proxy services

TIP8: Run IIS6 (if only for kernel caching)

TIP9: Using gzip compression

TIP10: View state of server space (ViewState)

Summarize

Other:

Common performance points

Using ASP.net to write Web applications is not as easy as it might seem. As simple as this, many developers will not take the time to structure their applications to improve performance. I'll talk about 10 points of attention to writing high-performance applications in this article. I am not limited to annotations to ASP.net applications because they are only a subset of Web applications. This article is not an authoritative guide to optimizing Web applications, but a complete book that simply focuses on (Web application optimization). In other words, think of it as an introduction to Web application optimization.

Before the formal start, I used to do some rock for climbing. Before the adventure of climbing, I would check the itinerary on the tour book and read some advice from people who had been there. But it doesn't matter how good the tour book is, before you try a particularly challenging climb, you need to climb the actual experience. Similarly, you can only learn how to write High-performance Web applications when you are faced with tuning performance problems or running high throughput sites.

My personal experience has been built up when I was in the Microsoft ASP.net team as a project manager for a lower-tier organization, which was primarily responsible for operating, managing www.asp.net, and providing support for the Architecture community Service (Architect Community Server), This community is the next version of several well-known asp.net applications (by asp.net forums. Text, and ngallery the composition of the platform). I'm sure these tips, which have helped me, will help you.

You should consider a reasonable layering of your applications. You may have heard of a 3-layer (or n-tier) physical architecture term, usually with a set of architectural templates to physically divide the functionality across or across hardware. More hardware can be easily added due to the size of the system. However, there is a point of reduction in performance related to processing and machine capability, so avoid it. So whenever possible, run the ASP.net page and its associated parts together in the same application.

Because of the separation between the code and the layers, the use of Web Services or remote calls can degrade performance by 20% or higher.

The data tier is a very special piece, because you typically use specialized hardware to support your database. However, the cost of processing a database is still high, so when you optimize your code, you should consider the performance of the data tier in the first place.

Make sure you analyze your application to find out where the problem is, before you get into the optimization of your application. Key energy points, such as the percentage of time spent in performing a garbage collection, are also useful in finding out where applications spend most of their time, so time-consuming places are often sensitive (unintuitive).

There are two ways to improve performance: large optimization, like using ASP.net cache, and repeatedly using your own micro-optimizations. These micro optimizations are sometimes the most interesting, and you modify a small portion of the code to bring in thousands of times the rewards. With large optimizations, you may see a big jump in overall performance. With a miniature, you may only be able to reduce the number of milliseconds for a given request, but there will be a huge performance boost when you mix the requests every day. performance of the data tier

When optimizing an application, there is a test that you can use to prioritize your work: code access to the database. If so, how do you usually do it? Note that the same test can also be applied to code that uses Web services or remote calls, but this article does not cover.

If you have a database request that must be in a particular code path, you look at other aspects such as the string operation you want to optimize first, and stop and perform your tests. Unless you have a serious performance problem, your time will be better utilized to optimize the time required to spend and connect to the database, the number of data returned, and the frequency of round-trip database operations.

With the general information identified, let's look at the 10 key points that can optimize your application, I ll begin with the changes that can make the biggest difference. Tip A multiple result set return

Then look at your database code to see if there is more than one path to the request database. Each data round-trip reduces the efficiency of the requests that your application can provide (the number of requests per second). By returning multiple results to a single database request, you can reduce the overall time spent communicating with the database, and you will also make your system more scalable and ease the pressure on the database server management requests.

You can use dynamic SQL to return multiple result sets, and I prefer to use stored procedures. It can be argued that business logic needs to be placed in stored procedures, but I think it's good if the logic in the stored procedure constrains the returned data (reducing the size of the dataset, the time spent on the network, and not having to filter the data at the logical level).

By using the SqlCommand instance and its ExecuteReader method to construct a strongly typed business class, you can move the pointer of the result set backward by calling NextResult. Figure 1 shows an example of converting multiple ArrayList into typed classes. Returning only the data you need from the database will reduce your server's memory footprint more.

Figure 1 Extracting multiple resultsets from a DataReader

Read the The ResultSet

Reader = command. ExecuteReader ();

Read the data from that resultset

while (reader. Read ()) {

Suppliers. ADD (Populatesupplierfromidatareader (reader));

}

Read the next ResultSet

Reader. NextResult ();

Read the data from that second resultset

while (reader. Read ()) {

Products. ADD (Populateproductfromidatareader (reader));

}

TIP 2 data access paging

Asp. NET's DataGrid controls are extremely powerful, including data paging support. When the paging feature of the DataGrid is enabled, a fixed number of results is displayed at once. In addition, the paging user interface can be displayed in the lower part of the DataGrid control to navigate the results. The paging user interface allows you to page backwards to display data, displaying a fixed number of results at a time.

Here's a disadvantage, and using the DataGrid to page pagination will bind all the data to the grid. For example, your data layer needs to return all the data and then filter the displayed results by the DataGrid based on the page of course. If 100,000 records are returned when you are paging through the DataGrid, then 99,975 records will be discarded per request (assuming 25 per page). As the number of records increases, the performance of the program is greatly impaired because more and more data is being requested for each request.

A good way to write better paging code is by using stored procedures. Figure 2 shows a stored procedure that pages the Orders table in a Northwind database. In this case, all you have to do is pass the index and page size of the two parameter pages, and the corresponding result set is computed and returned.

In the community service system, we are programmed with a paging service control to take care of all the data paging. For example, a WHERE clause is used to constrain the returned data, and the total number of returned records must be known, in order to calculate total pages to be displayed on the paging interface. For example, there are 1,000,000 records WHERE clauses are used to filter out 1,000, and paging logic needs to know the total number of records to render to the paging page accordingly.

Figure 2 Paging through the Orders Table

CREATE PROCEDURE northwind_orderspaged

(

@PageIndex int,

@PageSize int

)

As

BEGIN

DECLARE @PageLowerBound int

DECLARE @PageUpperBound int

DECLARE @RowsToReturn int

--The ROWCOUNT

SET @RowsToReturn = @PageSize * (@PageIndex + 1)

SET RowCount @RowsToReturn

--Set the page bounds

SET @PageLowerBound = @PageSize * @PageIndex

SET @PageUpperBound = @PageLowerBound + @PageSize + 1

--Create a temp table to store the select results

CREATE TABLE #PageIndex

(

IndexID int IDENTITY (1, 1) not NULL,

OrderID int

)

--Insert into the temp table

INSERT into #PageIndex (OrderID)

SELECT

OrderID

From

Orders

ORDER BY

OrderID DESC

--Return Total count

SELECT COUNT (OrderID) from Orders

--Return paged results