性能测试中单个虚拟用户的行为

性能测试中通常需要模拟大量用户或者流量来进行测试。那么有一个很重要的问题就是单个用户的行为是 怎样的。例如说如果我们要模拟 100 个人访问某一个网站,那么我们首先需要知道一个用户访问网站的流程,中间和服务器的交互过程是怎样的。这个部分通常会涉及到很多产品 或者协议的细节,但是因为这些细节会被测试执行过程中的大量并发所放大,所以在开始的时候把这些细节弄清楚、弄准确是很重要的,否则可能会差之毫厘,谬以 千里。

 

       下面给出一个关于 HTTP 协议的例子。

    在我们实验的某一个时间段访问新浪网的首页 (www.sina.com ), 发现共有 112 URL ,也就是说默认的情况下浏览器将发出 112 HTTP GET 请求来获得这些页面元素,包括文本、图片、动画等等。 HTTP 协议本身并没有严格的规定浏览器应该按怎样的 顺序,建多少个连接来取这些元素。从逻辑上简单分析一下,至少有下面的一些可能的做法。

  1. 每次建一个连接,每个连接取一个 URL 。那么需要依次的建立 112 TCP 连接,每次取完数据后断开,再建立下一个连接, 时间上没有重叠。这种方式实现起来最简单,但是可能效率不是很高。
  2. 建一个连接,不断的复用这个连接把所有的 URL 都取完,然后断开。这种方式建立的连接数最少,但是这 112 URL 也是依次取回的,所以和 a 相比,虽然省去了很多建连接的时间,但是取数据的 时候依然是串行的。
  3. 每次并发多个连接, 但是每个连接只取一个 URL ,也就是说连接不被复用。这种情况相比上面两种要复杂一些,因为引入了并行,可以有多个连接同时存在,使得取数据的效率有所提高。但是 因为每个连接还是只取一个 URL ,所以总的连接数还是 112 个。
  4. 每个并发多个连接,每个连接可以被重复使用多次来取得多个 URL 。这种方式在 c 的基础上进一步扩展,将并发连接和连接复用结合到了一起。相比而言是一个更经济又高效的方式。

对于 HTTP 协议相关的性能测试,之所以要考虑上面的实 现方式,是因为 TCP 连接的建立和维护是需要开销的,而且实际的产品和测试工具对并发连接数的支持通常也是有限制的。在测试的执行过程中,上面的差异将会被 极大的放大,比如有一个 1000 个并发的虚拟用户,那么这些差异就会被放大 1000 倍。建 1000 个连接和建 112 000 个连接的开销是远远不同的,同样 1000 个并发连接和 10000 个并发连接(以 d 中每个虚拟用户并发 10 个连接来计算)对被测设备的压力也是完全不一样的。

上面谈到的其实和 HTTP 协议目前的两个版本, 1.0 1.1 ,有很大的关系。 HTTP 连接过程中使用的方式也依赖于通信双方 (HTTP client server) 的约定。目前实用的大部分浏览器都支持 最后一种方式。尽管我们知道了这一点,但是对于性能测试来说还是不够具体,那就是上面提到的并发多个 连接每个连接重 复使用多次 还是显得太含糊了。而且我们也不能确定不同的浏览器采用的策略和数值是一样的。与其去猜测,不如通过实际的测试和分析来 得到有参考性的数据。下面我们采用 4 种不同的浏览器来访问上面提到的新浪的首页,看看这些浏览器是如何取回这 112 URL 的。这里用来评估的四种浏览器包括 IE6 SP2, Firefox 2, Firefox 3, Chrome 0.4.154.25 。在访问的过程中,我们使用抓包和协议分析工具 Wireshark 来捕获浏览器和服务器交互的数据,来分析连接的情况。下面给出了用 IE 访问时的一次结果。需要说明的是,由于使用了代 理,这里看到的服务器端变成了本地代理和它的 8080 端口。

 

1        访问数据的抓包结果

每 次和服务器建立新的连接的时候都会换用一个不同的 TCP 端口,所以我们可以按照 src port 排序来列出所有的端口和每个端口发起的请求次数。下面的表中给出 了几次测试的一些统计结果。

1 不同浏览器的连接次数

浏览器

第一次测试的总连接数

第二次测试的总连接数

IE6

30

26

Firefox 2

30

33

Firefox 3

26

26

Chrome

101

30

 

从上面的数据我们可以看出,在大部分情况下,浏览器建立的连接数还是在一个较小的范围,但是有时候 也可能会有较大的波动。上面的测试结果可能会有一定的随机性,但是如果我们要进行相关的性能测试,还是可以提供不少的参考,给我们模拟真实用户使用浏览器 访问的时候提供了实践性的依据。

       在上面截图的底部,我们可以看到浏览器在发送 HTTP GET 请求时发出的数据,包括 HTTP header ,这些也是我们在性能测试中需要模拟的部分。

 

大家可能会问另一个问题,哪一个是真实的呢?其实这些都是真实的,因为都是市面上大家在用的浏览器 的行为。要回答这样一个问题,要结合被测系统可能的部署情况。简单的来说,如果被测系统的浏览器用户基本上是 IE 的话,那么测试的时候就应该模拟 IE 的行为,反之亦然。对于一些在公网上的应用,或 许将两种浏览器行为按一定的比例混合是一个更贴近真实情况的做法。比如之前程序员杂志就做过一个研究,得出在某段时间访问 CSDN 的网站的浏览器的比例, IE, Firefox, Chrome, Opera 等各占多少,如果要做这样的网站的性能测试,那么这可能是一个很好的参考依据。

通过上面的分析和研究,我们知道了我们想要模拟的单个用户的行为,那么接下来的问题是我们如何借助 工具模拟出这样的行为。好在很多的测试工具都可以让测试人员灵活的来配置这些行为。比如每个虚拟用户最大并发多少个连接,每个连接最多被复用多少次,对每 个服务器的最大并发连接数等等,还有些可以选择你要模拟的浏览器类型。下图中给出的是 Avalanche 提供的相关配置。

 

2 Avalanche HTTP 协议相关的配置

       从上面的截图中,我们可以看到,测试人员可以根据具体的情况来选择模拟的 HTTP 协议的版本和特性,并且可以控制前面提到的一些连接相关的参数。

 

       上面给出的 HTTP 的例子其实是比较简单和容易理解的,在实际产品的测试中,所谓的单个用户的行为会复杂很多,所以在 一开始的时候我们要耐心的弄清楚一个用户的行为。你如果想着,这个行为会被放大很多,也许就会觉得你现在在做的事情很重要。

3   Avalanche HTTP 协议相关的配置,浏览器类型

在上图中我们可以看到, Avalanche 允许测试人员选择要模拟的浏览器的类型和版本。当选择了不同的浏览器之后,相应的参数,包括 HTTP header 也会跟着变化,当然用户也可 以自己定制。

 

 

by Ricky Q.

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值