ASP.NET性能優化之負載均衡
1：HTTP重定向
所謂HTTP重定向，就是通過修改HTTP響應頭中的Location標識為新的URL，然后返回給客戶端，讓客戶端重新根據這個Location標識的URL去做新的請求。
這是一種最簡單、也是最輕量級的負載均衡實現方案，使用asp.net，我們可以這樣來實現，比如在主站www.yourdomain.com中，我們在默認主頁如下編碼：
- 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]);
- }
在上面的代碼中，Response.Redirect實際為http頭返回狀態碼302，這是為了告訴瀏覽器，請到Location中去拿URL，并且去到這個新的URL去做請求。當然，我們也可以采用最原始的方法來代替Redirect方法：
- Response.Status = "302 Found";
- Response.StatusCode = 302;
- Response.AddHeader("Location", servers[DateTime.Now.Millisecond % 2]);
使用HttpWatch監視，我們對www.yourdomain.com請求，得到：
可以清晰的看到第一次請求返回的302，然后轉發到新的地址，得到狀態碼200。
以上方法是在客戶端的重定向，即瀏覽器請求了兩次，一次是到主服務器，第二次是到Location中指定的服務器上去請求。
HTTP重定向的方式非常依賴于主站的處理能力，它的性能瓶頸也是來自于IIS對于接受請求->asp.net處理首頁動態程序->返回帶有特定頭請求，是的，它不能突破自身的性能瓶頸，比如，在我的破測試機上，我得到的吞吐率為：
好在IIS自身已經支持重定向（查閱http://technet.microsoft.com/zh-cn/library/cc732969(WS.10).aspx），這更進一步省略了我們自己寫代碼實現重定向，省略運行ASP.NET代碼帶來的性能損耗。
2：varnish實現的反向代理負載均衡
另外一種思路是使用反向代理服務器的負載均衡功能，上篇當中介紹的varnish就支持這樣的功能，查看配置文件：
- 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);
- }
在該配置文件中，我們部署了兩臺WEB服務器，當然，為了簡單期間，我這里是使用了同一臺服務器的兩個端口。在vcl_recv函數中，varnish定義了負載均衡。
運行varnish之，我們會發現請求被轉發到后臺服務器了。
3：其它方案
1：DNS負載均衡，通過增加域名A記錄來讓DNS服務器實現負載均衡。好處是幾乎不會碰到性能問題。缺點：要求每個WEB服務器必須有外網地址。一旦某臺服務器崩潰，不能及時讓DNS修改生效。不能定義自己的轉發策略；
2：IP負載均衡，有LVS-NAT，采用iptables，對LINUX內核操作，性能相對于反向代理服務器并沒有質的飛躍；IP負載均衡仍舊需要轉發請求給實際服務器，同時需要轉發實際服務器的響應給用戶，所以，它的性能瓶頸來自于NAT服務器的性能及網絡帶寬；
3：直接路由，有LVS-DR，工作在數據鏈路層（第二層），要求所有WEB服務器接入外網；負載均衡器負責轉發請求給實際服務器，但是它通過修改數據包中的MAC地址，能夠做到讓實際服務器的響應直接返回給用戶，而不用通過負載均衡器，這當然進一步提升了負載均衡的效率；
4：IP隧道，有LVS-TUN，用于不同機房（即不同WAN網段）的負載均衡，原理同LVS-DR；
原文地址：http://www.cnblogs.com/luminji/archive/2012/05/16/2184280.html
【編輯推薦】
