Guide: Author Yanyang wrote a series of articles about asp.net. I have a period of time did not write asp.net things, in the mind always feel that the lack of what, after all, their own asp.net still love a single clock. In this series of articles, to prepare a more comprehensive about asp.net performance optimization, from the front to the background, later this Levin also see as a handbook for everyone to inquire! Here's what the article reads:
Aspects of website optimization to consider
When developing a Web site with asp.net, performance is always a matter of concern, and performance is not just the speed at which the code executes, it's about everything.
Take a request from ASP.net, from the browser to the server's ASP.net Web site to send the request began to the end of the entire page in front of us, where the request passed each step, there are different ways of tuning, and the method is called a lot, not only common: caching, multithreading, asynchronous and so on.
The articles in this series decide on tuning in two big ways:
Foreground tuning: mainly includes how to minimize HTTP requests, starting from HTTP requests, to how to load JS, CSS, how to compress the data transmitted.
Background tuning: Analyze the processing of the asp.net request, and give the corresponding tuning method at each step, and give a tuning method on the code organization, architecture and database operations.
Remember that when you just developed a Web site, the easiest and fastest way to think about improving performance is caching, and it's also recommended in some of Microsoft's official best practice documents: Layers of caching (in the data storage layer, DAL,BLL,UI, etc.). Then in the site on the "cache everywhere", the last is really unsatisfactory.
Another common optimization is for the database: such as minimizing subqueries, using join joins, and indexing on fields that often need to be queried. Indeed, these are some of the rules that are very generic and good.
And there is also the experience that, in the optimization of performance, if you choose to optimize the code and database, it is often better to optimize some of the operations of the database, unfortunately: in the project (at least in some projects I developed), the database is just a data storage device, nothing more, Did not play a powerful role in the database. Therefore, it is recommended to be familiar with the internal query and storage mechanism of the database, after all, many times the developer also acts as a DBA (many companies do not have a formal DBA).
And in the project we design the database, especially when the table field, it needs some consideration, many people suggest that the length of the table field is not too long, this is a common suggestion, but why? In fact, this needs to understand some of the internal storage mechanism of the database: when the database (SQL SERVER) is saved, the data is "page" for the smallest unit, each page has 8 k size, if you have more than 8K of data in a table, then the table data will be divided into several pages to save, In this way, when querying the data, it is necessary to cross-page query, spread is the need for performance consumption, if the data are on a page, then the speed must be faster.
Therefore, to optimize the site, you need to know where the performance consumption.
When the optimization of a site, not blindly generalize, in general there are two situations:
1, the site already exists, and run, and now to optimize.
2. A new website is being developed from scratch.
If this is the first case, then first of all to find out the bottleneck of the performance of the site, from the front of the request to the background of the request processing, until the final page of the presentation, will be a step-by-step review.
If this is the second case, it might be a little bit better, and the site is now completely under our control, all of which can be optimized in the process of development and design with many optimization principles.
Optimization is not necessarily code rewrite or make a lot of changes, the optimization of a little bit of accumulation, just like the code refactoring, is a cumulative effect. For example, in the beginning of the page to load the JS script, or the entire page at the end of the load JS script, sometimes just simply adjust the load file, or asynchronous loading script, or through the CDN transfer scripts and so on, performance has been improved. Performance improvement is not without cost, and some costs are very small, such as just the loading of the script at the end of the page, the big Price is, for example, buy some server equipment, such as content Delivery Network (CDN) to the static file (Js,css,image) to the client. So, optimization needs to weigh the strategy.
Do not know whether you have this experience: when looking at their own development of the system can be very good, they are very confident, on the contrary, if the system is very slow, sometimes really do not want to say that the system is their own.