在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