rogerliu0303 发表于 2017-5-17 23:51:08

新人求助。请大家帮忙看看,我测试的流程有没有问题

以前是做自动化的,最近被迫要搞性能测试。不懂的实在太多,请各位帮我指点。
先说下背景,被测程序是一个wcf服务,基于NETTCPBinding。测试工具是我自己写的一个简易的多线程wcf客户端。在线程函数中,每次请求前、请求后各打一个时间戳,然后相减,作为响应时间。然后把这个时间和当前系统时间一起写进结果文件里。再用另一个程序,通过结果文件里的系统时间,计算吞吐量:从第一个结果记录开始获取每一秒钟内的请求数量,作为QPS.然后计算这一秒内所有请求的平均响应时间,然后把QPS和平均响应时间关联,输出一个报表。
想大家帮我看看,我对QPS,响应时间等等这些值的理解对么,采集数据的逻辑对么?

chenmaosen 发表于 2017-5-18 10:44:57

术语说明:
QPS = req/sec = 请求数/秒

QPS统计方式
QPS = 总请求数 / ( 进程总数 *   请求时间 )
QPS: 单个进程每秒请求服务器的成功次数

哈哈,网上抄了个。你看看

其实我对你描述的用秒计算会存在几点的疑虑:
(1)我们压测常用参考的结论QPS是压测时间段内的平均结果。如果按照每秒进行统计计算一个QPS是每秒可能都是不一样的,如果再用这些每秒的数据进行平均是做了处理后的数值平均,个人担心是不太准确
(2)你上面描述上没有提及到成功失败的请求是否会独立计算。这里一般需要给出单次压测的成功率,用来确认本次压测是否有效(例如成功率低于95%,可能就是无效压测,失败率太高,流程不完整)
(3)响应时间也是一样,需要一个总和再除的过程,个人觉得总的QPS和响应时间可能更有价值,注意响应时间打标内除接口调用响应外不做额外工作。但如果你完成了总的计算,再额外增加你现在所说的每秒统计也是可以帮助分析。
至于线程发压是否均匀、线程中断的恢复、通过日志分析(一般高压力我们尽量会减少日志的输出,避免发压能力的降低,每个请求不断写io也是资源呀)是否能够精准的问题得自己慢慢排坑

rogerliu0303 发表于 2017-5-18 12:53:02

chenmaosen 发表于 2017-5-18 10:44
术语说明:
QPS = req/sec = 请求数/秒



之所以算每秒的值是为了绘制chart。报告里的QPS和响应时间会按平均值算。
程序有排错,请求失败是单独统计的。
您最后说的问题,是我这两天一直在考虑的问题,怎么能让线程最大程度并发,发压均匀。还有,写文件确实占了很大资源,但是不得不输出文件,有什么降低资源消耗 的方式没。。。请多指点

chenmaosen 发表于 2017-5-18 13:17:45

均匀性问题,我这边的经验会考虑使用调度执行分离的方式
通过调度分配服务,获取到所需并发数、总任务数后,进行计算分配给不同的执行服务进行执行。
这种方式比较适合扩展为多机发压的方式。(有时候发压机型不一样,还得按不同机型分配不同的任务并发数)

最大程度的并发说法个人人为有点不全面,并发数其实是你的连接数,句柄够连接过去即可,然后就是不断的收发包(这过程可能会有机型资源不足,就看你自己排坑了)。
有些框架的调度会选择一次分配给发压进程一百个包或者1千个等,可以实时输出压测的进度,减少通讯。
线程级会有自己线程的切换调度可能还得深入了解下当中的坑,这个你做的过程中会有发掘解决的过程,以前未使用过这个方式,这边不误人了哈哈
资源问题是否可以考虑内存,速度快点,但资源得评估下是否足够

jingzizx 发表于 2017-5-18 13:55:33

建议是要考虑是否计算数据合理,不要考虑资源占用,如果写文件占资源多,就找个资源多的电脑安装客户端,保证数据准确
页: [1]
查看完整版本: 新人求助。请大家帮忙看看,我测试的流程有没有问题