Turn: Building a high-performance ASP. NET Site to analyze the page processing process (front-end)

Build a high-performance ASP. NET Site to analyze the page processing process (front-end)

When optimizing ASP. NET websites, it is sufficient to understand ASP. NET. In the process of optimization, we usually first find out where the problem may exist, and then prove that the problem is to be solved. After confirmation, we will take some measures. The structure of the series of articles is as follows: first introduce the optimization of the front-end, I will mark the "front-end" behind the title of the article, if it is the optimization of the background code, I will mark the "backend" on the title. If it is for database design optimization, I will mark the "Database" on the title. I hope you will give more suggestions.

 

This article mainly analyzes the process and gives you a comprehensive understanding. The next article will start step-by-step analysis.

 

The topics in this article are as follows:

Analyze the page parsing process

Analyze possible optimization points

 

Analyze the page parsing process

The process of page Parsing is not the process of lifecycle of ASP. NET pages. The browser requests a page and then presents the page.

 

In this article, I will first describe the page parsing process, display the overall description, and then propose optimization methods at each point. Overall, partial.

 

When the browser requests a Web page, it starts from the URL. The process is described as follows:

1. Enter a URL or click a URL.

2. the browser parses the IP address corresponding to the URL Based on the URL address and DNS.

3. Send an HTTP request

4. Start to connect to the server of the request and request-related content (as to how the request is processed, we will not discuss it here for the time being, but will discuss it later)

5. the browser parses the content returned from the server, displays the page, and continues with other requests.

 

The above is basically the process of a page being requested to reality. Next we will start to analyze this process.

 

After a URL is entered, the browser must know the IP address of the URL. Only when the IP address is known can the browser send the request to the specific IP address and port number of the specified server.

 

The browser's DNS parser is responsible for resolving the URL to the correct IP address. This resolution takes time, and the browser cannot download anything from the server during the parsing period. However, this parsing process can be optimized. Imagine that if the browser needs to parse each request to a URL, each request consumes a little time, which may be very short, however, the performance improvement is a little bit of "tuning. If the corresponding URL and IP address are cached, when the same URL is requested again, the browser does not need to parse it, but directly reads the cache, which is bound to be faster.

 

In fact, browsers and operating systems provide such support.

 

After obtaining the IP address, the browser sends an HTTP request to the server. Let's take a look at how the request was sent:

1. the browser requests the server to open the connection by sending a TCP packet

2. The server also sends a packet to respond to the browser of the client and tells the browser that the connection is enabled.

3. the browser sends an http get request, which contains many things, such as common cookies and other head header information.

 

In this way, a request is sent.

 

After the request is sent, It is the server. For example, the file clearly defined by the browser is an ASP.. NET page, the server sends the request to ASP through IIS. NET runtime, after a series of activities, the final result, of course, is generally sent to the client in the form of html.

 

In fact, the first thing that comes to the browser is the html documents. The so-called html documents are pure html code that does not contain any images, scripts, css, etc. That is, the html structure of the page. This is because only the html structure of the page is returned. The time for sending this html document to the browser is very short, usually about 10% of the total response time.

 

Then, the basic skeleton of the page is in the browser. The next step is the process of parsing the page by the browser, that is, parsing the html skeleton step by step from top to bottom.

 

If the img tag is encountered in the html document at this time, the browser will send an HTTP request to the URL of the img response to obtain the image and then present it. If there are many images and flash files in the html document, the browser will send requests one by one and then present them.

 

At this point, we may feel that this method is a little slow. Indeed, the request for this image and other resource files can be optimized. Not to mention anything else. If each image requires a request, perform the steps mentioned earlier: parse the url, open the tcp connection, and so on. Opening a connection also consumes resources. Just like accessing a database, we try to open as few database connections as possible and use connections in the connection pool as much as possible. Likewise, tcp connections can be reused. But there is also a problem with reuse: If the URLs of the two images are as follows:

 

 

Code

 

 

The time consumed to request these images is as follows:

 

 

 

 

First, you can see the top yellow line. This yellow line indicates that the browser opens the connection. The second half of the yellow line is blue, indicating that the browser has requested html documents.

 

The second Blue Line at the top indicates that the first image has been requested. At this time, the request for this image is still a tcp connection.

 

When you see the third line, the front part is yellow, indicating that another tcp connection is enabled when you request the second image. The second half of the line is blue, indicates that the image has been requested.

 

The remaining images to be requested all use the previous tcp connection.

 

Indeed, tcp connections are fully used, but the image download speed is indeed slow. We can see that the images are downloaded sequentially. The response time of the entire page can be imagined.

 

If you use the following method, for example:

 

 

 

It can be seen that there are more connections, but almost all images are downloaded in parallel, which is much faster.

 

 

In fact, this is a trade-off.

 

In fact, the browser also has built-in optimization methods, such as cache images and scripts. Or, when we talk about parallel download, we can see that it will consume more connection resources.

 

Today, we have made a preliminary analysis of the page process. We have a general understanding of the process. We will gradually optimize the process in the next article. Please pay attention to it and hope you will give more comments and feedback. Thank you! :)

 

From: http://www.cnblogs.com/yanyangtian/archive/2010/07/22/1782670.html