ASP.NET性能優(yōu)化之負載均衡的方法
發(fā)布時間:2012-05-17 10:22:47 作者:佚名
我要評論

ASP.NET性能優(yōu)化之負載均衡的代碼
HTTP重定向
所謂HTTP重定向,就是通過修改HTTP響應頭中的Location標識為新的URL,然后返回給客戶端,讓客戶端重新根據(jù)這個Location標識的URL去做新的請求。
這是一種最簡單、也是最輕量級的負載均衡實現(xiàn)方案,使用asp.net,我們可以這樣來實現(xiàn),比如在主站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頭返回狀態(tài)碼302,這是為了告訴瀏覽器,請到Location中去拿URL,并且去到這個新的URL去做請求。當然,我們也可以采用最原始的方法來代替Redirect方法:
Response.Status = "302 Found";
Response.StatusCode = 302;
Response.AddHeader("Location", servers[DateTime.Now.Millisecond % 2]);
使用HttpWatch監(jiān)視,我們對www.yourdomain.com請求,得到:

可以清晰的看到第一次請求返回的302,然后轉(zhuǎn)發(fā)到新的地址,得到狀態(tài)碼200。
以上方法是在客戶端的重定向,即瀏覽器請求了兩次,一次是到主服務器,第二次是到Location中指定的服務器上去請求。
HTTP重定向的方式非常依賴于主站的處理能力,它的性能瓶頸也是來自于IIS對于接受請求->asp.net處理首頁動態(tài)程序->返回帶有特定頭請求,是的,它不能突破自身的性能瓶頸,比如,在我的破測試機上,我得到的吞吐率為:

好在IIS自身已經(jīng)支持重定向(查閱http://technet.microsoft.com/zh-cn/library/cc732969(WS.10).aspx),這更進一步省略了我們自己寫代碼實現(xiàn)重定向,省略運行ASP.NET代碼帶來的性能損耗。
2:varnish實現(xiàn)的反向代理負載均衡
另外一種思路是使用反向代理服務器的負載均衡功能,上篇當中介紹的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函數(shù)中,varnish定義了負載均衡。
運行varnish之,我們會發(fā)現(xiàn)請求被轉(zhuǎn)發(fā)到后臺服務器了。
3:其它方案
1:DNS負載均衡,通過增加域名A記錄來讓DNS服務器實現(xiàn)負載均衡。好處是幾乎不會碰到性能問題。缺點:要求每個WEB服務器必須有外網(wǎng)地址。一旦某臺服務器崩潰,不能及時讓DNS修改生效。不能定義自己的轉(zhuǎn)發(fā)策略;
2:IP負載均衡,有LVS-NAT,采用iptables,對LINUX內(nèi)核操作,性能相對于反向代理服務器并沒有質(zhì)的飛躍;IP負載均衡仍舊需要轉(zhuǎn)發(fā)請求給實際服務器,同時需要轉(zhuǎn)發(fā)實際服務器的響應給用戶,所以,它的性能瓶頸來自于NAT服務器的性能及網(wǎng)絡帶寬;
3:直接路由,有LVS-DR,工作在數(shù)據(jù)鏈路層(第二層),要求所有WEB服務器接入外網(wǎng);負載均衡器負責轉(zhuǎn)發(fā)請求給實際服務器,但是它通過修改數(shù)據(jù)包中的MAC地址,能夠做到讓實際服務器的響應直接返回給用戶,而不用通過負載均衡器,這當然進一步提升了負載均衡的效率;
4:IP隧道,有LVS-TUN,用于不同機房(即不同WAN網(wǎng)段)的負載均衡,原理同LVS-DR;
作者 Luminji
所謂HTTP重定向,就是通過修改HTTP響應頭中的Location標識為新的URL,然后返回給客戶端,讓客戶端重新根據(jù)這個Location標識的URL去做新的請求。
這是一種最簡單、也是最輕量級的負載均衡實現(xiàn)方案,使用asp.net,我們可以這樣來實現(xiàn),比如在主站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頭返回狀態(tài)碼302,這是為了告訴瀏覽器,請到Location中去拿URL,并且去到這個新的URL去做請求。當然,我們也可以采用最原始的方法來代替Redirect方法:
Response.Status = "302 Found";
Response.StatusCode = 302;
Response.AddHeader("Location", servers[DateTime.Now.Millisecond % 2]);
使用HttpWatch監(jiān)視,我們對www.yourdomain.com請求,得到:

可以清晰的看到第一次請求返回的302,然后轉(zhuǎn)發(fā)到新的地址,得到狀態(tài)碼200。
以上方法是在客戶端的重定向,即瀏覽器請求了兩次,一次是到主服務器,第二次是到Location中指定的服務器上去請求。
HTTP重定向的方式非常依賴于主站的處理能力,它的性能瓶頸也是來自于IIS對于接受請求->asp.net處理首頁動態(tài)程序->返回帶有特定頭請求,是的,它不能突破自身的性能瓶頸,比如,在我的破測試機上,我得到的吞吐率為:

好在IIS自身已經(jīng)支持重定向(查閱http://technet.microsoft.com/zh-cn/library/cc732969(WS.10).aspx),這更進一步省略了我們自己寫代碼實現(xiàn)重定向,省略運行ASP.NET代碼帶來的性能損耗。
2:varnish實現(xiàn)的反向代理負載均衡
另外一種思路是使用反向代理服務器的負載均衡功能,上篇當中介紹的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函數(shù)中,varnish定義了負載均衡。
運行varnish之,我們會發(fā)現(xiàn)請求被轉(zhuǎn)發(fā)到后臺服務器了。
3:其它方案
1:DNS負載均衡,通過增加域名A記錄來讓DNS服務器實現(xiàn)負載均衡。好處是幾乎不會碰到性能問題。缺點:要求每個WEB服務器必須有外網(wǎng)地址。一旦某臺服務器崩潰,不能及時讓DNS修改生效。不能定義自己的轉(zhuǎn)發(fā)策略;
2:IP負載均衡,有LVS-NAT,采用iptables,對LINUX內(nèi)核操作,性能相對于反向代理服務器并沒有質(zhì)的飛躍;IP負載均衡仍舊需要轉(zhuǎn)發(fā)請求給實際服務器,同時需要轉(zhuǎn)發(fā)實際服務器的響應給用戶,所以,它的性能瓶頸來自于NAT服務器的性能及網(wǎng)絡帶寬;
3:直接路由,有LVS-DR,工作在數(shù)據(jù)鏈路層(第二層),要求所有WEB服務器接入外網(wǎng);負載均衡器負責轉(zhuǎn)發(fā)請求給實際服務器,但是它通過修改數(shù)據(jù)包中的MAC地址,能夠做到讓實際服務器的響應直接返回給用戶,而不用通過負載均衡器,這當然進一步提升了負載均衡的效率;
4:IP隧道,有LVS-TUN,用于不同機房(即不同WAN網(wǎng)段)的負載均衡,原理同LVS-DR;
作者 Luminji
相關文章
AudioContext 實現(xiàn)音頻可視化(web技術分享)
這篇文章主要分享的是web技術的 AudioContext 實現(xiàn)音頻可視化,要實現(xiàn)音頻可視化得先實現(xiàn)一些炫酷的效果需要借助 Web Audio API提供的一些方法 AudioContext,下面詳細內(nèi)容2022-02-23- 這篇文章主要給大家介紹了web技術中的WebRTC記錄音視頻流,文章內(nèi)容圍繞主題展相關資料,需要的小伙伴可以參考一下,希望對你有所幫助2022-02-23
- 這是我通過網(wǎng)上查閱資料總結的一些編碼規(guī)范,用于鞏固對html,css頁面重構時的基礎,需要的朋友可以參考下2020-12-19
前端編碼規(guī)范(4)—— CSS 和 Sass (SCSS) 開發(fā)規(guī)范
這篇文章主要介紹了前端編碼規(guī)范(4)—— CSS 和 Sass (SCSS) 開發(fā)規(guī)范,需要的朋友可以參考下2017-01-21Web前端開發(fā)規(guī)范2017(HTML/JavaScript/CSS)
這是一份旨在增強團隊的開發(fā)協(xié)作,提高代碼質(zhì)量和打造開發(fā)基石的編碼風格規(guī)范,其中包含了 HTML, JavaScript 和 CSS/SCSS 這幾個部分。我們知道,當一個團隊開始指定并實行2017-01-21- 這篇文章主要為大家介紹了前端開發(fā)團隊遵循和約定的代碼書寫規(guī)范,意在提高代碼的規(guī)范性和可維護性,需要的朋友可以參考下2017-01-21
- 這篇文章主要為大家詳細介紹了響應式Web之流式網(wǎng)格系統(tǒng)的相關資料,感興趣的小伙伴們可以參考一下2016-07-04
在網(wǎng)頁標題欄上和收藏夾顯示網(wǎng)站logo的實現(xiàn)方法
下面小編就為大家分享一篇在網(wǎng)頁標題欄上和收藏夾顯示網(wǎng)站logo的實現(xiàn)方法。希望對大家有所幫助。一起跟隨小編過來看看吧,祝大家游戲愉快哦2016-03-16Visual Foxpro 6.0 中文版安裝向?qū)?圖解)
基于很多用戶都在下載Visual Foxpro 6.0,但是有安裝vtp6.0經(jīng)驗的朋友確很少,在安裝過程中總會出現(xiàn)這樣那樣的問題,基于這些問題,下面小編抽個時間把Visual Foxpro 6.02015-09-09網(wǎng)站日志200 0 64狀態(tài)碼的分析(協(xié)議子狀態(tài))
網(wǎng)站日志200 0 64狀態(tài)碼的分析介紹2012-10-29