在Azure中使用Load Runner測試TCP最大併發鏈接數

對於Azure中的每一臺虛機，它所能支持的TCP最大併發鏈接數是50萬(參考微軟官網: http://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/#networkinglimits)。在絕大部分狀況下，應用程序不會觸及這一限制，從而感受不到這個限制的存在。可是，在一些極端狀況，例如咱們設計這樣一個測試案例：在Azure中建立一臺虛機，並安裝Nginx服務器。使用多臺Load Runner客戶端，持續向Azure中的這臺服務器發送HTTP請求。當Load Runner的客戶端機器個數足夠多，而且網絡環境良好，這樣的測試有可能會達到50萬併發鏈接數的限制。

爲何會有這個限制？有以下緣由：

1. Azure做爲公有云平臺，是一個共享的平臺。咱們不但願個別用戶或者虛機，佔用了絕大部分的平臺資源。這樣，對平臺上的其餘用戶是不公平的。

2. 根據咱們的調研，絕大部分應用程序在這個限制下徹底能夠正常工做。

若是應用程序須要比50萬更多的併發鏈接怎麼辦？解決方案以下：

1. 橫向擴展應用服務器。例如一臺服務器支持50萬，那麼兩臺就是100萬。這個數字跟隨機器數的增長而線性增加。

2. 調整創建TCP鏈接的方法。例如創建長鏈接或鏈接池。

下面，咱們詳細講解一個測試案例，供讀者參考。

測試案例分享：

硬件環境：

在同一個公有云平臺的區域中，使用1臺2核虛擬機做爲服務器， 4臺4核的虛擬機做爲客戶端分別對服務器進行壓力測試。

軟件環境：

在服務器上，運行Ubuntu 操做系統。此外安裝Nginx 1.4.6做爲Web Server。統一部署一個4個字節的index.html文件，用做測試網頁的下載。

在客戶端上，運行Windows操做系統， 安裝HP Load Runner 11，針對服務器的地址進行壓力測試。每臺客戶端上，Load Runner 模擬200個用戶同時向服務器發送5分鐘請求，獲取全部的事務tps信息，包括成功，失敗和停止。

在Load Runner下，編寫以下腳本進行測試。其中[URL]的部分根據不一樣的環境進行修改。

Action()
 { 
 web_url(「webserver", 
 "URL=[URL]", 
 "Resource=0", 
 "RecContentType=text/html", 
 "Referer=", 
 "Snapshot=t1.inf", 
 "Mode=HTML", 
 LAST);
 
 return 0;
 }

例如:

網絡環境：

筆者經過兩種方式進行了這項測試，獲得一樣的測試結果。第一種方式，咱們將Load Runner安裝在Azure平臺的虛機中。第二種方式，經過本地數據中心的Load Runner向Azure中的虛機發起請求。網絡拓撲結構以下。請注意，這裏畫出的四臺客戶機只是示意，在實際的測試中，咱們使用了2臺、4臺、6臺和8臺的多種場景。

測試結果：

在測試初期，咱們將Load Runner跑在Azure中，獲得了以下的TPS圖形。

從上面的途中咱們在一臺Load Runner中看到，當每秒處理的事務數達到430的時候（這時咱們共有6臺機器，服務器端的TPS在430x6=2500TPS左右），服務器忽然不接受任何新的請求，TPS驟然間變成了0。通過排查，咱們發現該測試觸及了另外一個限制 - 每一個雲服務開放的TCP源端口不得超過64000。

要繞開這一限制，有兩個方法：

1. 將Load Runner放到不一樣的雲服務中。

2. 爲每臺測試機指定Public IP。http://msdn.microsoft.com/en-us/library/azure/dn690118.aspx

爲虛機指定了Public IP後，或者使用本地機房的物理機所謂客戶端，咱們即獲得了下面的測試結果：

上面的測試持續1小時9分鐘，咱們並無發現TPS驟降的現象。這一現象說明，在咱們的測試中，服務器的50萬併發鏈接限制沒有影響客戶端的結果，從而也不會影響客戶體驗。

結論：

在實際的應用程序設計中，咱們能夠根據具體的應用程序場景，運用本文談到的測試方法，來獲得系統的指標 - 一臺服務器可支持的併發事務處理數(TPS)。一般，服務器處理的瓶頸並不在於TCP併發鏈接數，而是系統的處理能力，例如數據庫查詢等。接下來，咱們須要檢驗本身的應用程序是否能夠橫向擴展，經過增長多臺服務器，比較測試結果，咱們就能夠了解橫向擴展的性能變化。根據這兩個指標（單臺機器處理能力，橫向擴展性能指標），咱們就能夠預估系統的規模。

本文轉載自：http://blogs.msdn.com/b/cciccat/archive/2014/08/18/azure-load-runner-tcp.aspx