大用户量测试性能遇到的几个问题。欢迎进来讨论

jaunty

1.首先对于脚本的transaction放置的位置讨论。
我们整体业务大概会有5种请求加压到 待测服务器上 而且根据不同的业务情况 请求发送的数量及哪些请求会被发送 都不一样。比如说 r1 r2 r3 r4 r5 。当用户一登陆就必然发出r1和r2，如果用户符合某种情况还会发出r3， 另外每10分钟会做一次检测 如果检测有必要会发出r1和r4, 关闭系统和退出系统的时候必然会发出r5 如果检测有必要会发出r1和 r4
就是业务大概就这么分布。
我想测试单业务并发和多业务并发入手。
原先我们的脚本设计是 从登陆系统发出3个请求，直到等10分钟系统监测发出新的请求 加上退出登陆时触发的请求登 一系列连续的动作坐在一个脚本里。然后copy了3次 因为有3个大的业务快会触发这5个请求中的某些。讲登陆设置为一个transaction，中间10分钟检测作为一个transaction，退出登录作出一个transaction。

这样的出来tps必然不是最细到每个请求的。不知道这样设计场景是否合适？

2.对于最佳并发用户数和最大并发用户数的估算。
现在且不说最佳。我想估算一个平均的并发用户数和峰值的并发用户数。

我现在能拿到的数据就是当天内曾经使用过系统的独立的用户数目。目前大概是80w一天 （登陆使用过），设计期望的单台服务器的qps大概能是200个请求每秒

对于平均并发用户量的估算，这几天看了很多方法，从粗的到精确的。
例如最著名相对科学的，来自国外专家eric提出的泊松分布法则
计算公式为
c=nL/T

c = 平均并发用户数
n = login session的数量
L = login session的平均长度，即从登陆到退出的平均时间长度
T =为考量上面login session的整个时间段

并发用户数的峰值 = c+3倍根号c


首先利用第一个公司算一个平均并发用户数就遇到个问题，我们系统根本没有采集过login session的平均时长，也没有做过这样的统计。因为公司业务众多且用户量奇大无比，统计组不会统计到很细的。就像那天我想问一个高峰时期的同时在线人数都没有。
因此这个公司我放弃

然后从第二个公式下手：
我只把qps当成平均用户并发量，但是其实抽象到业务层面，这并不成立，qps数目并不等于系统里有多少个用户。一个用户他可以发出多个请求。我就算有qps也很难推测出大概我lr要加多少个用户数。（请大家要注意qps是指服务端单位时间处理的同时的请求数，它是纯物理的并发），但是我们在lr里要加的vuser数目是基于业务层面的。



3. 大用户量的测试资源准备问题:
假设有2000个用户并发，每个用户都有自己的数据。难道大家每个用户都是自己注册并且数据都是自己造的？那我们待测系统支持的人越多那岂不是光准备数据都能把人累死？
另外再ipspoofer这里，如果我假设不同vusr不同的ip的话。那我得希望我们局域网里有这么多ip才行。这太扯了吧？是否我自己虚拟一个网络以及虚拟出很多ip，只要我服务器的路由表里有这些ip就可以实现了呢？
再者对于用户量及并发量越大的话 我的generator也要求的越老越多。 按照目前我收集的一台2g内存的机器减掉机器跑其他程序的内存声誉资源最多虚拟出来400多个用户（1个用户占4m内存计算），当然我们不能把generator变成测试瓶颈，按照我从很多高人那里获取的资料一般一台机器的资源占用到60%的时候已经算是最佳中的最大虚拟用户量了。我算了下大概就是虚拟出100~200用户。 如此推算。假设我要测试1000个用户并发那可就得10台机器，那之后我再更大用户量，那generator可得多少台啊。


以上均为本人按照目前经验总结出来的问题和观点，欢迎大家指点及讨论！！

[ 本帖最后由 jaunty 于 2010-3-22 22:12 编辑 ]

jaunty

顶 怎么没人回复？
昨晚细读了段念的书中关于 响应时间的解释及并发用户的估算。我更加确定qps不能直接拿来估算并发用户数了 qps毕竟是服务端的一个考量。 但是可以这个数据根据某种方法抽象或者估算的出。。。。

云层

额，问题太大，看完就要很多时间，要想清楚怎么回答又很麻烦，先占位

jaunty

顶上去  欢迎大家出来讨论
关于第一个大问题，我已经按照业务点来划分transaction了。不知道这么可行不先试验一下。例如登陆时有可能发出r1,r2的请求 或者r1,r2,r3这种请求。至于第3个请求是否发送取决与当时用户的实际情况（有逻辑判断）。我就将r1,r2做成一个登陆1的transaction 并且是一个独立脚本， r1,r2,r3就做成另外一个transaction叫登陆二并且是做成另外一个独立脚本的。

欢迎大家讨论！！

jaunty

为什么还没人来答

JonnyGu

不太懂楼主的意思，弱弱地回答一下，划分transaction是按照需求来的，比如你想得到哪些动作的response time，一般来说都是一个step一个transaction，比如登录就是一个动作，那么就加一个transaction了。

jaunty

原帖由 JonnyGu 于 2010-3-24 14:59 发表
不太懂楼主的意思，弱弱地回答一下，划分transaction是按照需求来的，比如你想得到哪些动作的response time，一般来说都是一个step一个transaction，比如登录就是一个动作，那么就加一个transaction了。

你的登陆就发出一个请求？没有其他的了？
就举个例子 登陆会发出2个请求，有的用户如果符合条件的就会发出3个请求。
假如是你对登陆这块的transaction，你怎么分？

JonnyGu

这跟请求的多少没有关系，用户关心的是我点击login这个button之后到成功login需要多久，所以只需要一个transaction，这是我的理解。

3396408

对于问题1，实际做得时候我是把每组请求都加上事务，不同组的事务按照一定得比例加压到场景里面，这样实际测试出来得结果对于各种事务都有度量了。

peag

我站位，有空来瞧瞧

云层

简单看了一下，基本上你说的差不多

2.并发这种东西可以直接到服务器上去看，反而比你算的准
3.本来做负载就需要很多load generator，ip地址简单，你做个b类局域网就行了，数据么，用工具生成就好了