web| Program | skills | performance | skills | performance skills
Author: Rob Howard
This article discusses
• Common ASP.net performance difficulties
• Useful performance tips and tricks for asp.net
• Recommendations for using the database in asp.net
• Caching and background processing using asp.net
This article uses the following techniques:
asp.net,. NET Framework, and IIS
Content of this page
Data-tier performance
Tip 1-Return multiple result sets
Tip 2-Paging data access
Tip 3-Connection pool
Tip 4-asp.net Cache API
Tip 5-per-Request cache
Tip 6-Background processing
Tip 7-page output caching and proxy server
Tip 8-run IIS 6.0 (as long as the kernel cache is used)
Tip 9-Use Gzip compression
Tip 10-Server Control view state
Summary
The simplicity of using asp.net to write Web applications is unbelievable. Because of this simplicity, many developers will not spend time designing their application structures for better performance. In this article, I'll describe 10 tips for writing high-performance WEB applications. But I'm not going to limit these suggestions to asp.net applications, as they are just part of the WEB application. This article does not serve as an authoritative guide to performance tuning of WEB applications-a whole book I'm afraid will not be able to easily explain the problem. Consider this article as a good starting point.
I used to like rock climbing before I became a workaholic. Before doing any big rock climbing, I will first take a closer look at the route in the guide and read the advice from previous visitors. However, no matter how good the guide is, you need a real climbing experience before you can try a particularly challenging climb. Similarly, when you are faced with a problem fixing a performance problem or running a high throughput site, you can only learn how to write high-performance Web applications.
My personal experience comes from the ASP.net department in Microsoft as an infrastructure program manager, during which I run and manage www. asp.net, which helps design the structure of community servers, is a community server that is known as several asp.net applications (combined to a platform of asp.net forums. Text and Ngallery). I'm sure some of the techniques that have helped me will certainly help you.
You should consider dividing an application into several logical tiers. You may have heard of the term 3-layer (or n-tier) physical architecture. These are usually a well defined architectural approach that physically separates functionality from process and/or hardware. It's easy to add more hardware when the system needs to be expanded. However, there is a performance degradation associated with process and machine jumps and should therefore be avoided. So, if possible, run the ASP.net page and its related components together in the same application.
Because of code separation and the boundaries between layers, using WEB services or remoting can degrade performance by 20% or more.
The data tier is a bit different because, in general, it's best to have hardware dedicated to the database. However, the cost of a process jumping to a database is still high, so the performance of the data tier is the first thing you should consider when optimizing your code.
Before you dive into the performance fixes for your application, first make sure you dissect your application to find out what the problem is. Major performance counters, such as counters that represent the percentage of time required to perform garbage collection, are also useful for finding out where an application is spending its primary time. However, the location of the time spent is usually very not intuitive.
This article describes two types of performance improvements: large optimizations (such as using asp.net caching), and small optimizations that replicate themselves. These small optimizations are sometimes particularly interesting. You'll get a lot of time when you make a small change to your code. With large optimizations, you may see a larger leap in overall performance. With small optimizations, it may only save a few milliseconds for a particular request, but a significant improvement can be achieved by adding all the requests each day.
Data-tier performance
When it comes to application performance tuning, there is a test strip that can be used to prioritize work: Does the code access the database? If so, what is the frequency? Note that this same test can also be applied to code that uses WEB services or remoting, but this article does not cover these content.
If a database request is required in a particular code path, and you think you want to first optimize other areas (such as String operations), stop and then perform this test. If your performance problem is not very serious, it's a good idea to spend some time optimizing the time spent on the database, the amount of data returned, and the round-trip frequency to and from the database.
With these general information in view, let's take a look at 10 tips that might help improve application performance. First, I want to talk about the changes that might make the most difference.
Back to the top of the page
Tip 1-Return multiple result sets
Review your database code to see if there are multiple request paths to enter the database. Each such round-trip reduces the number of requests per second that the application can provide. By returning multiple result sets in a database request, you can save the total length of time required to communicate with the database. It also makes the system more scalable because it reduces the ability to manage requests for database servers.
Although you can use dynamic SQL to return multiple result sets, I prefer to use stored procedures. There are some controversies about whether business logic should reside in stored procedures, but I believe that if the logic in the stored procedure can constrain the return of data (reducing the size of the dataset, shortening the time spent on the network, and not having to filter the logical layer of data), you should be in favour of doing so.
When you populate a strongly typed business class with the SqlCommand instance and its ExecuteReader method, you can move the result set pointer forward by calling NextResult. Figure 1 shows an example of populating several ArrayList with a type class. Returning only the data you need from the database will further reduce the memory allocation on the server.
Back to the top of the page
Tip 2-Paging data access
The ASP.net DataGrid has a good feature: data paging support. When paging is enabled in the DataGrid, a fixed number of records is displayed at a time. In addition, the paging UI is displayed at the bottom of the DataGrid to navigate between records. The paging UI enables you to navigate forward and backward between the displayed data and to display a fixed number of records at a time.
And there's a little twist. Paging using the DataGrid requires that all data be bound to the grid. For example, if your data tier needs to return all the data, the DataGrid will filter all the records that are displayed based on the current page. If 100,000 records are returned when paging through the DataGrid, 99,975 records are discarded for each request (assuming 25 records per page size). As the number of records increases, the performance of the application is affected because more and more data must be sent for each request.
An excellent way to write better paging code is to use stored procedures. Figure 2 shows a sample stored procedure for paging to the Orders table in the Northwind database. In short, all you have to do now is pass the page index and page size. The appropriate result set is then computed and returned.
In the Community server, we have written a page-and-sever control to complete all the data paging. As you'll see, I'm using the idea discussed in Tip 1, which returns two result sets from a stored procedure: the total number of records and the requested data.
The total number of returned records may vary depending on the query being executed. For example, the WHERE clause can be used to constrain the returned data. To calculate the total number of pages that are displayed in the paging UI, you must know the total numbers of records to return. For example, if you have a total of 1,000,000 records and you want to filter it to 1000 records using a WHERE clause, the paging logic needs to know the total number of records to render the paging UI correctly.
Back to the top of the page
Tip 3-Connection pool
Setting up a TCP connection between a WEB application and a SQL Server™ can be a very resource-consuming operation. Microsoft developers have been able to use connection pooling for some time so far, allowing them to reuse database connections. Instead of setting up a new TCP connection for each request, they set up a new connection only if there are no connections in the connection pool. When the connection is closed, it returns to the connection pool, where it maintains a connection to the database rather than completely destroying the TCP connection.
Of course, you need to be careful whether a leak connection will occur. Be sure to close these connections when you are finished using the connection. Repeat: No matter what anyone does to Microsoft? NET Framework, be sure to call Close or Dispose explicitly on the connection when you are finished using the connection. Do not trust the common language Runtime (CLR) to clear and close the connection for you at a predetermined time. Although the CLR eventually destroys the class and forces the connection to close, it is not guaranteed when garbage collection against the object actually occurs.
To use connection pooling in the most optimized way, you need to follow some rules. First open the connection, perform the action, and then close the connection. If you must, you can turn the connection on and off multiple times for each request (preferably with tip 1), but do not keep the connection open all the time and pass it in and out in a variety of different ways. Second, use the same connection string (if you use integrated authentication, use the same thread identity). If you do not use the same connection string, such as customizing the connection string based on the logged-on user, you will not be able to get the same optimization value that the connection pool provides. If you use integrated authentication and also simulate a large number of users, the efficiency of connection pooling can be greatly reduced. . NET CLR Data Performance counters can be useful when trying to track any performance issues associated with connection pooling.
Whenever an application connects to a resource, such as a database running in another process, you should focus on the time spent connecting the resource, the time it takes to send or retrieve data, and the number of round-trip trips to optimize. Optimizing any kind of process jump in your application is the primary point in getting better performance.
The application layer contains the logic to connect the data layer and transform the data into meaningful class instances and business processes. For example, a community server where you populate a forums or threads collection, apply a business rule (such as permissions), and most importantly, execute caching logic in it.
Back to the top of the page
Tip 4-asp.net Cache API
Before writing the line of application code, one of the first things to do is to design the structure of the application layer to maximize the use of the ASP.net caching feature.
If your component is to run in an ASP.net application, simply include a system.we in the application project
