在Azure中使用Load Runner测试TCP最大并发连接数

[アーティクル]
08/17/2014

对于Azure中的每一台虚机，它所能支持的TCP最大并发连接数是50万(参考微软官网: https://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。https://msdn.microsoft.com/en-us/library/azure/dn690118.aspx

为虚机指定了Public IP后，或者使用本地机房的物理机所谓客户端，我们即得到了下面的测试结果：

上面的测试持续1小时9分钟，我们并没有发现TPS骤降的现象。这一现象说明，在我们的测试中，服务器的50万并发连接限制没有影响客户端的结果，从而也不会影响客户体验。

结论：

在实际的应用程序设计中，我们可以根据具体的应用程序场景，运用本文谈到的测试方法，来得到系统的指标 - 一台服务器可支持的并发事务处理数(TPS)。通常，服务器处理的瓶颈并不在于TCP并发连接数，而是系统的处理能力，例如数据库查询等。接下来，我们需要检验自己的应用程序是否可以横向扩展，通过增加多台服务器，比较测试结果，我们就可以了解横向扩展的性能变化。根据这两个指标（单台机器处理能力，横向扩展性能指标），我们就可以预估系统的规模。

次の方法で共有