友善交流技术...

由10并发引起的思考

上一篇 / 下一篇 2012-08-08 17:10:59 / 个人分类：性能测试专题

这几天也在围绕一个问题在说事？并发到底是什么？网络上有各自的解释，也有各自的道理。我总结如下

并发分广义和狭义之分

1)广义并发：多业务之间的并发，当然也有可能是同一个业务的并发（这个几率比较低），这种并发更加接近真实的场景，一个系统如果对外开放，就会面临多个业务同时操作的问题，那么这个业务操作按什么比例来进行呢？

大家都会想到分析日志或是历史数据，我想告诉大家的是：分析日志或是历史数据指的是吞吐量，和我们平时说的并发用户数是一个概念吗？我的回答是：NO。TPS ! =并发用户数，那么怎么解决这个换算的问题，有人提出一个办法，做基准测试，得到响应时间，然后 TPS*响应时间＝vuser ,最后也算是计算出业务模型了，但是这个响应是这么算的吗？响应是一个固定的值吗？做过性能测试的人都知道，响应时间随用户数理的变化而变长的，如果这个值能计算出来，我们还有必要做性能测试吗？那这样一推理不就出来了吗，这个计算公式就失去了存在的意义，业务模型失真了，方法又失败了。。。我们现在按并发用户百分比=业务模型的百分比，当然这个是有问题的。

测试策略：(1)按流程将脚本控制不同循环次数来进行

(2)将脚本拆分成多个脚本来进行百分比分配

2)狭义并发：指同一个业务之间的并发，同一个时间内，都在做一件事情。

测试策略：

1)测试本接口中加for，while循环控制执行次数，如1000次，目的是让并发用户都做一样事情

2）增加集合点关注的事务增加集合点

这几天一直在思考的问题：并发10个用户怎么解理

并发就会涉及到时间颗粒度的问题，以秒为单位还是以毫秒为单位呢?loadrunner目前的并发和我们认为的并发是一个概念吗？

如下有几个人不同的看法：

1）每一秒发10个请求

有人认为，以秒为单位，每一秒固定的请求，持续运行2小时，这样的需求其实也不算为过的，但是目前市场上没有一个工具可以支持这种方式的压力。你可能会问我，为什么不支持，原因如下：它不会等待服务器给你返回结果，所以每一秒都要创建新的线程来做这样的事情，大家都知道loadrunner(10000) & 操作系统端口个数是65535 ，资源都是有限度的，不可能一直创建，然后你可能又要问我了，为什么不重复使用这个线程或是端口呢? 问题就出来了，loadrunner现在没有办法在场景中或是脚本中来重复使用线程，或是其它的开源工具都不会自己检测或回收这个线程，需求自己做工具，这样工具量可能不亚于重新开发一个loadrunner工具。但是我也没有明白，loadrunner为什么不设计这样的场景呢？

2) 10并发＝TPS

也有人认为10并发就是10个TPS，在网上有部分人这样认为，说是服务器的角度来考虑并发的问题。可以使用loadrunner 基于目标的测试场景来做。

我的问题是：如果是2个并vuser，满足10个TPS的话，你说这个性能测试有问题吗？如果按这个数据来设计链接数或是线程池你感觉会有问题吗？我的回答是：有问题的，如果突然有100个请求同时过来的话，你的服务器就会拒绝请求了。原因是，你配置的参数太小了。所以这种测试方法，也有它的缺点所在

3)集合点

有人认为增加集合点就是并发,但是这个压力似乎比较小的，为什么，它需要等待其它用户完成后，大家再次集合并发，在这个时间段内，早完成的vuser处于等待状态，对服务器来讲压力是变小了。这个其实就没有达到10并发的要求。我们可以理解中间增加了thinktime时间的并发。

4)loadrunner10个并发

每一个线程都是一个在指定时间内的死循环运行的。但是这个并发就会涉及到等待服务器返回值的问题。

其实我们现在就是面临狭义并发意见不统一的问题。

人个感觉，其实并发概念并不重要的，重要的是能衡量系统的TPS，就是系统的吞吐量是比较重要的。但是TPS也是按业务之间的比例进行的，所以本人认为还是测试综合场景比较接近真实的场景的，接近用户的行为。

不管怎么讲，性能测试就是要以用户为中心，尽可能的模拟用户的行为，提前暴露系统的问题，发现问题，解决问题。

今天就写到这吧。

收藏举报