ASP. NET performance optimization-Load Balancing

1: HTTP redirection

The so-called HTTP redirection is to identify the new URL by modifying the location in the HTTP Response Header, and then return it to the client, so that the client can make a new request based on the URL identified by the location.

This is the simplest and most lightweight Load Balancing implementation solution. We can use Asp.net to implement it like this. For example, in the main site www.yourdomain.com, we encode the following code on the default homepage:

?

Static String [] Servers = { "Http: // 192.168.0.77/luminji2/aspx/test3.aspx" , "Http: // 192.168.0.77/luminji2/aspx/test4.aspx" }; Protected Void Page_load ( Object Sender, eventargs E) { Response. Redirect (servers [datetime. Now. millisecond % 2]); }

AboveCodeIn, response. Redirect actually returns the status code 302 for the HTTP header. This is to tell the browser, please go to location to get the URL and go to the new URL for the request. Of course, we can also use the most primitive method to replace the Redirect method:

?

Response. Status ="302 found";Response. statuscode = 302;Response. addheader ("Location", Servers [datetime. Now. millisecond % 2]);

For httpwatch monitoring, we request www.yourdomain.com and get:

You can clearly see the 302 returned for the first request, and then forward it to the new address to get the status code 200.

The above method is redirection on the client, that is, the browser requests twice, one to the master server, and the second to the server specified in location.

The HTTP redirection method relies heavily on the processing capability of the master site. Its performance bottleneck also comes from IIS's Dynamic Homepage for receiving requests-> Asp.net ProcessingProgram-> A request with a specific header is returned. Yes, it cannot break through its own performance bottleneck. For example, on my broken test machine, I get the following throughput:

Fortunately, IIS itself supports redirection (check the http://technet.microsoft.com/zh-cn/library/cc732969 (ws.10). aspx), which further omits the performance loss caused by running ASP. NET code by writing our own code to achieve redirection.

2: reverse proxy load balancing implemented by Varnish

Another idea is to use the Server Load balancer function of the reverse proxy server. The varnish mentioned in the previous article supports this function and view the configuration file:

?

Backend web1 { . Host = "192.168.0.77 "; . Port = "8081 "; } Backend web2 { . Host = "192.168.0.77 "; . Port = "8082 "; } Director LB round-robin { { . Backend = web1; } { . Backend = web2; } }   Sub vcl_recv { Set Req. backend = LB; Return (PASS );   }

In this configuration file, we have deployed two Web servers. Of course, for the sake of simplicity, I use the two ports of the same server. In the vcl_recv function, varnish defines load balancing.

When varnish is run, we will find that the request is forwarded to the backend server.

3: Other solutions

1. DNS load balancing: Add domain name a records to enable the DNS server to achieve load balancing. The advantage is that there are almost no performance problems. Disadvantage: each web server must have an Internet address. Once a server crashes, the DNS modification cannot take effect immediately. You cannot define your own forwarding policy;

2: IP load balancing, LVS-NAT, using iptables, Linux kernel operations, performance compared with the reverse proxy server does not have a qualitative leap; IP load balancing still needs to forward requests to the actual server, at the same time, the response from the actual server needs to be forwarded to the user. Therefore, the performance bottleneck of the server comes from the performance and network bandwidth of the NAT server;

3: Direct routing, LVS-DR, working on the data link layer (Layer 2), requiring all Web servers to access the Internet; Load balancer is responsible for forwarding requests to the actual server, however, by modifying the MAC address in the data packet, the server can directly return the response from the actual server to the user without using the Server Load balancer, which further improves the efficiency of Server Load balancer;

4: IP tunnel, LVS-TUN, used in different data centers (that is, different WAN network segments) load balancing, the principle of the same LVS-DR;

 

Source: http://www.cnblogs.com/luminji/
The copyright of this article is shared by the author and the blog. You are welcome to repost this article, but you must keep this statement without the author's consent andArticleThe original text connection is displayed at an obvious position on the page.

The so-called HTTP redirection is to identify the new URL by modifying the location in the HTTP Response Header, and then return it to the client, so that the client can make a new request based on the URL identified by the location.

This is the simplest and most lightweight Load Balancing implementation solution. We can use Asp.net to implement it like this. For example, in the main site www.yourdomain.com, we encode the following code on the default homepage:

?

Static String [] Servers = { "Http: // 192.168.0.77/luminji2/aspx/test3.aspx" , "Http: // 192.168.0.77/luminji2/aspx/test4.aspx" }; Protected Void Page_load ( Object Sender, eventargs E) { Response. Redirect (servers [datetime. Now. millisecond % 2]); }

In the above Code, response. Redirect actually returns the status code 302 for the HTTP header, In order to tell the browser, please go to location to get the URL and go to the new URL for the request. Of course, we can also use the most primitive method to replace the Redirect method:

?

Response. Status ="302 found";Response. statuscode = 302;Response. addheader ("Location", Servers [datetime. Now. millisecond % 2]);

For httpwatch monitoring, we request www.yourdomain.com and get:

You can clearly see the 302 returned for the first request, and then forward it to the new address to get the status code 200.

The above method is redirection on the client, that is, the browser requests twice, one to the master server, and the second to the server specified in location.

The HTTP redirection method relies heavily on the processing capability of the main site. Its performance bottleneck also comes from the IIS's response to the request-> Asp.net homepage dynamic processing program-> response request with a specific header, yes, it cannot break through its own performance bottleneck. For example, on my broken test machine, I get the following throughput:

Fortunately, IIS itself supports redirection (check the http://technet.microsoft.com/zh-cn/library/cc732969 (ws.10). aspx), which further omits the performance loss caused by running ASP. NET code by writing our own code to achieve redirection.

2: reverse proxy load balancing implemented by Varnish

Another idea is to use the Server Load balancer function of the reverse proxy server. The varnish mentioned in the previous article supports this function and view the configuration file:

?

Backend web1 { . Host = "192.168.0.77 "; . Port = "8081 "; } Backend web2 { . Host = "192.168.0.77 "; . Port = "8082 "; } Director LB round-robin { { . Backend = web1; } { . Backend = web2; } }   Sub vcl_recv { Set Req. backend = LB; Return (PASS );   }

In this configuration file, we have deployed two Web servers. Of course, for the sake of simplicity, I use the two ports of the same server. In the vcl_recv function, varnish defines load balancing.

When varnish is run, we will find that the request is forwarded to the backend server.

3: Other solutions

1. DNS load balancing: Add domain name a records to enable the DNS server to achieve load balancing. The advantage is that there are almost no performance problems. Disadvantage: each web server must have an Internet address. Once a server crashes, the DNS modification cannot take effect immediately. You cannot define your own forwarding policy;

2: IP load balancing, LVS-NAT, using iptables, Linux kernel operations, performance compared with the reverse proxy server does not have a qualitative leap; IP load balancing still needs to forward requests to the actual server, at the same time, the response from the actual server needs to be forwarded to the user. Therefore, the performance bottleneck of the server comes from the performance and network bandwidth of the NAT server;

3: Direct routing, LVS-DR, working on the data link layer (Layer 2), requiring all Web servers to access the Internet; Load balancer is responsible for forwarding requests to the actual server, however, by modifying the MAC address in the data packet, the server can directly return the response from the actual server to the user without using the Server Load balancer, which further improves the efficiency of Server Load balancer;

4: IP tunnel, LVS-TUN, used in different data centers (that is, different WAN network segments) load balancing, the principle of the same LVS-DR;