Considerations for building a high-performance ASP. NET Website

Considerations for website Optimization

In useASP. NETWhen developing a website, performance is always a matter of consideration and attention. performance is not only the speed of code execution, but also related to all aspects.

Take ASP. for a request from the web browser to the server's ASP.. NET website sends the request until the end of the page is displayed in front of us. each step of the request has a different tuning method, and there are many calling methods, it is not just common: caching, multithreading, and Asynchronization.

This article has decided to introduce Optimization in two major aspects:

Foreground Optimization: It mainly includes how to minimize http requests, from http requests to how to load js, css, and how to compress transmitted data.

Background Optimization: Analyzes the processing process of ASP. NET requests, and provides corresponding optimization methods in each step. It also provides Optimization Methods for code organization, architecture, and database operations.

I remember that when I was developing a website, when I mentioned how to improve performance, the easiest and fastest possible thing to think of was caching. In some Microsoft Best Practice documents, I also suggested: layer-by-layer caching (caching at the data storage layer, DAL, BLL, and UI ). Then, on the website, "the cache is blooming everywhere", and the final result is indeed unsatisfactory.

Another common optimization is for databases: for example, to minimize the number of subqueries, join is used; and indexes are created on fields that are frequently queried. Indeed, these are common and good rules.

Another experience is that, when optimizing performance, if you choose to optimize code and database, some database operations are often optimized to bring better results, but unfortunately: in projects (at least in some projects I have developed), databases are just a data storage device, and they have not played a powerful role in the database. Therefore, it is recommended that you be familiar with the internal query and storage mechanisms of databases. After all, many developers also work as DBAs (many companies do not have formal DBAs ).

In addition, when designing databases in projects, especially table fields, we need to consider some issues. Many people suggest that the length of table fields should not be too long. This is also a common recommendation, but why? In fact, we need to understand some internal storage mechanisms of the database: When the database (SQL SERVER) is saved, the data is in the smallest unit of "page, each page has a size of 8 K. If the data in your table exceeds 8 K, the data in this table will be saved on several pages. In this way, when querying the data, cross-page query is required. Cross-page query requires performance consumption. If data is on one page, the speed is certainly faster.

Therefore, to optimize the Website, you must know the performance consumption.

When optimizing a website, it is not blindly generalized. Generally, there are two situations:

1. The website already exists and runs. Now we need to optimize it.

2. A new website is being developed from scratch.

If this is the first case, we should first find out the bottleneck of the website performance, from the front-end request to the back-end request processing, until the presentation of the last page, all of which should be reviewed step by step.

In the second case, the situation may be slightly better, and the website is completely controlled by us now. Many optimization principles can be used in all development and design processes.

Optimization does not necessarily mean code rewriting or making major changes. A little bit of accumulation during optimization is like code refactoring, which is a cumulative effect. For example, whether to load the js script at the beginning of the page or load the js script at the end of the page, sometimes it is just a simple adjustment of the loaded file, or asynchronously load the script, or transmit the script through CDN, the performance is improved. The performance improvement is not zero, and some costs are very small. For example, if you just load the script to the end of the page, the big cost is, for example, buy some server devices, for example, Content Delivery Network (CDN) is used to transmit static files (js, css, and image) to the client. Therefore, optimization requires a balance strategy.

I don't know if you have had this experience: When you look at the system performance you have developed, you are very confident. On the contrary, if the system is slow, sometimes I really don't want to say that this system is self-built.