性能测试：一个时间问题
性能测试问题：单个功能业务点，测试60个用户并发一个业务点为7.145秒，
我做140个用户混合场景，7个功能点，每个功能点20用户，前面的那个7.145秒的业务功能现在20个并发为5.682秒，有人问我这个数据给客户验收时，怎么解释？
他的理由是，前面那个是60个用户，还7秒多，而后面140个用户并发时，怎么时间会少呢？
有高手给讲讲********** 这个很好解释啊。前面有60个用户的压力，后面实际的并发用户数只有20. 如果你觉得跟客户解释起来很麻烦
你就对这个功能单独做一个20用户并发再对比 不好讲，你需要验证你的20个并发用户产生的响应时间，当然需要考虑其他6个业务一起并发的情况下；
1.首先看下20个并发单独运行的并发响应时间，应该会小于5秒的
2.然后你增加其他的业务，可以进行逐级增加，得出响应时间
这样你可能向用户解释比较好点 第一次基准测试是 1功能点 60并发。 PT = 7S
第二次测试是 7功能点 140并发。 PT = 5S（我觉得这样不好比对）
但是如果他说 前面那个是60个用户，还7秒多，而后面140个用户并发时，怎么时间会少呢？
你可能需要看一下AP的系统资源了...
例如 第一次基准你的CPU 是 40%，那么第二次可能就达到了70% 。
抛去 其他功能点的干扰，1功能点的第一次基准测试已经达到了瓶颈。第二次分担的只有第一次的3/1压力，所以降低了许多，但是不是直线降低而是抛物线。
为什么是抛物线？ 因为1颗CPU = 100%功率的话，那么两颗CPU应该是小于200%的功率，两个人干活需要沟通，需要磨合。。。 可以比较一下总的Action平均时间、或者总的TPS等等。
如果异常，那可能就是环境问题了:lol 晕，他这环境没有问题。。
从他的数据来看完全正常。
一个服务器里面7个进程同时启用，多少都会相互影响的，如果只有一个进程启用，那么他在20用户并发的条件下响应时间一定小于 5.682 秒； 因为还有6个进程在工作，所以响应时间是5.682秒，比单进程情况会慢。
两次压力测试： 虽然 第一次是 1个进程 第2次是7个进程，但他们都在一个服务器环境下，可视为一个整体。那么只要根据两次压力的比对即可以说明这个正常原因：
1.70用户压力、1AP ： CPU = 40% （或内存等资源）
2. 140用户压力、1AP： CPT = 70% （或内存等资源）
这样看起来是不是就正常了？ 两次测试环境是否相同很难说清楚，随便都可以举出例子，例如你客户端没有差别，服务器也可能留有缓存了，因此第二次快。。。
多做几次测试（例如两次测试都重启一下服务器看看），多分析系统，多了解系统设计才能回答清楚。
[ 本帖最后由 peaksoftchen 于 2009-5-15 17:30 编辑 ]
回复 3# 的帖子
这个也是方法，因为按用户量来说，就会有问题，这个也是个难题
页:
[1]
