Compartilhar via


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

对于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并发连接数,而是系统的处理能力,例如数据库查询等。接下来,我们需要检验自己的应用程序是否可以横向扩展,通过增加多台服务器,比较测试结果,我们就可以了解横向扩展的性能变化。根据这两个指标(单台机器处理能力,横向扩展性能指标),我们就可以预估系统的规模。