10 secrets of asp.net to improve performance or scalability (2)

Introduction

Asp.net has many "secrets" worth exploring. When you discover them, it will greatly improve the performance and scalability of your website! For example, there are some secret bottlenecks for Membership and Profile providers, and they are easily resolved, making authentication and authorization faster. In addition, the http pipeline of asp.net can process each request to prevent attacks by executing unnecessary code. More than that, the asp.net workflow can completely exert its power by breaking through the default limits. The page segment output cache on the browser side (not on the server side) can significantly reduce the large amount of download time required for access requests. Loading on the desired user interface can bring a fast and stable experience to your website. Finally, content delivery network (CDN) and correct use of HTTP cache headers can make your website quickly respond.

In this article, you will learn these technologies to greatly improve the performance and scalability of your asp.net application. The following are the technologies to be discussed:

• Asp.net pipeline Optimization
• Asp.net Process configuration optimization
• What you need to do before the Asp.net website goes online
• Content Delivery Network (CDN)
• Browser cache Ajax call
• Best use of browser cache
• Load the required UI step by step to provide a fast and smooth experience
• Optimize the asp.net 2.0 Profile provider
• How to query the Membership table of asp.net 2.0 without turning the site offline
• Prevent DoS Attacks

Note: Only items in the black font are translated!

The above technology can be implemented on any asp.net website, especially those websites that use the Membership and Profile providers of asp.net 2.0.

Best use of browser cache

Use a unified URL

The browser caches the URL Based on the content. When the URL changes, the browser obtains a new version of the URL from the server. The URL can be changed through query parameters. For example,/default. aspx is cached in the client browser. If you request/default. aspx? 123. It will retrieve the content from the server. If you correctly set the Response Header for caching, the request response can also be cached in the browser. In that case, if the request parameter is changed, new content will be returned from the server. Therefore, when you want to get the response from the cache, make sure that you use a unified URL everywhere. A common error is that the www subdomain is sometimes ignored by the URL. For example, www.pageflakes.com/default.aspxis different from pageflakes.com/default.aspx. They will be cached separately.

Caching static content for a longer period of time

Static files can be cached for a longer period, such as one month. If you think you should cache the file for two days, this way, when you change the file, the user will be able to get it soon. Your idea is wrong! If you update a file cached through the Expires header, the new user can directly obtain the latest file, and the old user will be able to see only the old file until the expiration date of your local browser. Therefore, once you are using the Expires header to cache static files, you should use a value as large as possible.

For example, if you have set an Expires header to cache a file for three days, a user obtains the file today and stores it in the cache for the next three days. Another user obtains the file tomorrow and caches it for three days after the renewal. If you modify the file the day after tomorrow, the first user will see it on the fourth day, and the second user will see it on the fifth day. Therefore, different users will see files of different versions. As a result, you do not need to set a very small expiration date so that all users can get a new version soon. You will have to modify the File URL to ensure that each user immediately obtains the same latest file.

You can use the IIS manager to set the Expires header of the static file. You will learn how to set it later.

Use a cache-friendly file directory structure

Store the cached content in a public directory. For example, store all the images on your site to a static file instead of placing the images separately under different subdirectories. This will help you use a unified URL. For example, you can write:/static/images/somefile.gif anywhere.

Reuse public image files

Sometimes, we place public image files in several different virtual directories, so that we can write a very short path to reference the file. For example, you have an indicator.gif file under the root directory. You do this because you don't need to worry about different paths, and you can simply use the file name as a virtual URL. However, this is not conducive to caching. Each copy of such files is independently cached in the browser. Therefore, you should collect all the image files in the solution, place them in the same file, and reference them using the same path.

Change the file name when you want the cache to expire

When you want to change a static file, do not just update the file because it has been cached in your browser. You need to change the file name and all references to it to ensure that the browser downloads the new file. You can also store the file name in the database or the configuration file and dynamically bind the data to the URL (for example, append the version number after the request ).

Use a version number when accessing a static file

If you do not want your file to be messy due to multiple copies of the same file, you can use query parameters to identify different versions of the same file. For example, a GIF file can be accessed as follows:/static/images/indicator.gif? V = 1. When you want to change this indicator.gif file, you can overwrite the same file and update all references to this file as:/static/images/indicator.gif? V = 2. In this way, you can update the same file again, and you only need to update the version number.

Store files that can be cached to a different domain name

It is always a good idea to put static files under a different domain name. First, the browser can download static files through two concurrent connections. Another benefit is that you do not need to send cookies to static files. When you use static files as part of your Web application and place them in the same domain name as other files, the browser needs to send all asp.net Cookies and all other cookies generated by your Web application. This makes the request header very large (not necessary in fact) and wastes bandwidth. You do not need to send cookies to access these static files. Therefore, if you place these static files under another domain name, the cookies will not be sent. For example, place static files under the domain name www.staticcontent.com, and your website runs on www.dropthings.com. The so-called other domain names do not necessarily need to be another complete web site. It can only work with the current Web
An alias for the application sharing path.

SSL cannot be cached, so use SSL to the minimum extent

SSL-related content cannot be cached. Therefore, you need to place static text outside SSL. In addition, you should try to restrict the use of SSL only on secure pages (such as login pages and payment pages. Other websites use common HTTP requests. SSL encrypts the request and corresponding content, and brings additional load to the server. The encrypted content is larger than the content of a common file and therefore occupies more bandwidth during transmission.

Http post requests will never be cached

The cache only occurs in http get requests. Http post requests will never be cached. Therefore, any form of AJAX calls you want to cache must be http get requests.

Generate Content-Length Response Header

When you are using Web Service or HTTP Handlers to dynamically generate Content, make sure that you have set the Content-Length header. When the browser displays the Content-Length header to know how many bytes need to be downloaded, it can provide multiple Optimization Methods for faster data download. When this header is the current connection header, the browser can use the persistent connection more effectively. This prevents the browser from opening a new connection for each request. When there is no Content-Length header, the browser does not know how many bytes of data it will accept from the server, so the connection is always opened, and the data is retrieved from the server until the connection is closed. Therefore, you miss the advantage of "continuous" connection, which can greatly reduce the download time for small files such as CSS, JS, and images. (For continuous connection, please refer to my previous articles in the Comet Series)

How to configure static file caching on IIS

On the IIS manager, the Web site Properties window has an "HTTP header" tab, where you can define the Expires header for all requests processed by IIS. You can define whether to invalidate the content directly or expire after a certain number of days or a specific date. The second option (Expires after) uses "slide expiration" instead of "absolute expiration ". This is very useful because it applies to every request. No matter when a person requests a static file, IIS calculates the expiration date based on this item.

For dynamic pages processed by asp.net, handler can modify the Expires header and overwrite the default IIS settings.

Demand-based page loading to improve smooth User Experience

A good solution is to dynamically load HTML fragments and the required Javascript. In the dropthings project, I show how to do it in the following:

When you click the "Help" Link, it dynamically loads the Help content. This section of HTML is not parsed as part of the default. aspx page. Therefore, the content related to help does not affect the loading performance of the site itself. However, it is dynamically loaded only when the user clicks the "Help" link. When you click the "Help" link again, it can be read directly from the browser cache.

The principle is to send an XMLHttp call to a *. aspx page to obtain the html tag of the response, add the html code to a DIV container, and make the DIV visible.

In this way, you can split the UI content into many smaller *. aspx files. Although these files cannot contain javascript or stylesheet blocks, they can contain a large amount of html code that you need to display on demand. Therefore, you only need to load the most basic content.

Respond to DoS Attacks

Web Service is the easiest target for hackers to attack, because even a novice hacker may call a Web Service that consumes a lot of resources and drop a server. The Ajax start page is the best DOS attack target. If you only access the home page without protecting cookies, each attack creates a new user and requests a new page. The first access is the most resource-consuming one. However, it is the easiest way to hook up a website. You can try it by yourself by writing the following simple code:

The biggest surprise to you is that you will find that after two calls, you cannot get a valid response. However, this does not mean that you have successfully crashed the server. This is only because your request is rejected. You are glad that you no longer have access to any service, so you have implemented a Denial-of-Service (you think so ). We are happy to reject your service.

My approach is simple. I will record the number of requests sent by an IP address. When the number of requests exceeds a special value, the system rejects further requests within a certain period of time. The scheme is to record the caller's IP address in the asp.net Cache and maintain statistics on each request initiated. When the statistical value of an IP address exceeds the limit, the request for updating the IP address is rejected within 10 minutes. After 10 minutes, the system responds to the request from the IP address again.

I have a class called ActionValidator, which maintains statistics on some special operations, such as first access, re-access, asynchronous return, adding new parts, and adding new pages. It checks whether the specific operand of the specified IP address exceeds the limit value.

Enumeration includes the operation type, the limits for checking them, and a specific time for receiving services again.

In a static method, IsValid performs specific detection. If the request does not exceed the limit value, true is returned; otherwise, false is returned if the request needs to be rejected. You can also display the result on a page.

The cache key is constructed by the operation type and the client IP address. First, it checks whether there are entities related to the operation and IP in the cache. If not, start counting and record the IP address of the operation to the cache. The absolute expiration time of the cache item can be ensured that the cache item will be cleared after the duration and the count will start again. When an object is already in the cache, obtain the last access statistics and check whether the limit is exceeded. If not, increase the count. By doing this: Cache [url] = hit;, you do not need to store the updated value in the Cache again. Because the hit object reference is modified, updating it also means updating the object itself in the cache. In fact, if you store the cache again, the cache failure count will be re-counted and will lose the function of re-counting after a special duration.

The usage is very simple. On the default. aspx page:

I checked the special scenarios here, such as the first access, re-access, and re-sending.

Of course, you can add some Cisco firewalls to prevent DoS attacks. You will get a managed service provider to ensure that the entire network is immune to DOS and DDOS (Distributed DOS) attacks. However, these application-level DOS attacks cannot be blocked by hardware and must be implemented in your own code.

Only a few websites adopt this measure to prevent DOS attacks at the application level. Therefore, by writing a simple loop, accessing a Web page that consumes a lot of resources or continuously calling Web Services with your home bandwidth, you can easily drop a server.