精华内容
下载资源
问答
  • 接口各项性能测试指标

    千次阅读 2020-04-22 11:18:28
    6、吞吐量 一次性能测试过程中网络上传输的数据量综合 反映:服务器承受的压力(系统的负载能力) 7、吞吐率 单位时间内网络上传输的数据量。吞吐率=吞吐量 / 传输时间 即单位时间内处理的客户请求数据量 业务角度...

    1、事务

    用户发送请求 -> 服务器接收请求并处理 -> 服务器向DB获取数据 -> 生成用户的object(页面)并返回给用户
    

    2、QPS(TPS)

    系统每秒钟能处理的 request/事务 数
    QPS(TPS)=并发数 / 平均响应时间
    

    3、并发数

    系统同时处理的 **request/事务** 数
    

    4、并发用户数

    同时在线的用户数量
    计算公式:C=nL / T
    n是平均每天访问用户数,L是一天内用户从登录到退出的平均时间,T是考察时间长度(一天内多长时间有用户使用系统)
    

    5、请求响应时间

    从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,该过程所消耗的时间。
    简称TTLB,“Time To Last Byte”。从发起一个请求开始,到客户端接收到最后一个字节的响应所消耗的时间
    一般取平均响应时间。
    

    6、吞吐量

    一次性能测试过程中网络上传输的数据量综合
    反映:服务器承受的压力(系统的负载能力)
    

    7、吞吐率

    单位时间内网络上传输的数据量。吞吐率=吞吐量 / 传输时间
    即单位时间内处理的客户请求数据量
    业务角度,单位“请求数/秒”、“页面数/秒”
    网络角度,单位“字节/秒”
    

    8、点击率

    每秒钟用户向服务器提交的http请求数
    

    9、资源利用率

    服务器的CPU利用率,磁盘利用率等。
    监控、分析的作用
    
    展开全文
  • 接口性能测试指标汇总

    千次阅读 2019-05-05 18:11:17
    参考网址:https://www.cnblogs.com/yulia/p/7850896.html

    参考网址:https://www.cnblogs.com/yulia/p/7850896.html

    展开全文
  • 性能测试接口压测指标分析

    千次阅读 2020-11-26 14:25:53
    通常而言,Jmeter性能测试结果分析可从性能测试指标达成方面着手,然后再分析测试过程中出现的异常情况,逐一判断是否存在性能风险。 一、用户登录并发测试结果分析 1、提取测试指标 表1:用户登录并发性能指标 ...

    原文地址:https://zhuanlan.zhihu.com/p/36587675

    通常而言,Jmeter性能测试结果分析可从性能测试指标达成方面着手,然后再分析测试过程中出现的异常情况,逐一判断是否存在性能风险

    一、用户登录并发测试结果分析

    1、提取测试指标

    表1:用户登录并发性能指标
    测试项并发数业务成功率响应时间CPU使用率内存使用率
    用户登录100100%<=5秒<=80%<=80%

    2、测试指标分析

    1)并发数

    线程组设置为100个线程,运行过程中未出现任何异常,满足100个线程并发操作需求。

    2)业务成功率

    测试脚本中设置了断言,判断用户登录后是否出现“登录成功”字样,并设定了“断言结果”查看器,通过查看断言结果,全部通过,则说明登录全部完成,业务成功率为100%。

    用户登录断言结果

    3)响应时间

    结合Jmeter执行结果后的聚合报告分析,用户登录响应时间目标指标<=5秒

    聚合报告
    聚合报告

    性能指数Apdex(Application Performance Index)是一个国际通用标准,表示用户对应用性能满意度的量化值

    它提供了一个统一的测量和报告用户体验的方法,把最终用户的体验和应用性能作为一个完整的指标进行统一度量。

    图7- 47表示为通用用户满意度区域,0代表没有满意用户,1则代表所有用户都满意。实际业务系统开发过程中,1是团队的追求目标。

    针对ECShop用户登录业务,100个并发登录的APDEX指标如图7- 48所示。从图中可看出,所有请求的Apdex值都接近1,因此用户满意度优秀,也从侧面说明了服务器响应速度快。

    图7- 48用户登录100并发APDEX指标情况

    4)系统资源使用

    利用Jmeter监控系统资源,测试完成后结果如图所示

    通过上图分析,CPU处于正常状态,因此次测试场景运行时间短,所以波峰及波谷明显,但均未持续超过80%,内存几乎无变化,被测服务器内存使用率维持在20%以内。因此测试结果符合预期目标指标。

    5)数据库监控

    利用Spotlight监控到的服务器Mysql数据库在测试期间运行的SQL为SELECT,与被测登录业务对数据库操作吻合

    3、更新并发测试结果表

    通过上述测试指标分析,更新用户登录并发测试结果表如表7- 13所示。

    二、用户登录业务量测试结果分析

    1、提取测试指标

    2、测试指标分析

    1)响应时间

    测试完成,生成测试报告后,获取响应时间趋势图,如图7- 52所示。

    图7- 52 用户登录业务量测试响应时间图

     

    通过上图分析,采用90%采样数据,分析整个请求,任何一个请求均未超过5秒,因此响应时间通过。

    2)业务成功率

    测试过程中所有断言通过,并且没有任何错误,登录成功率100%。“打开首页”、“打开用户登录页面”、“提交登录信息”与后面请求数据存在差异,是因为测试时间到达后部分请求立刻停止,故未能保证业务的完整性。

    3)业务量

    本次业务量测试,设置线程数为78个,2小时完成登录总数为8427次登录,其中包含了11秒操作停留时间,如果去除11秒停留时间,从数据理论计算,2*60*60/0.131=54961次,可达到预期2小时5万次登录操作,需进一步测试

    4)系统资源使用

    通过Jmeter监控服务器CPU及内存使用率来看,CPU及内存使用率非常稳定,且维持在20%-30%之间,满足预期目标不超过80%,测试通过。

    图7- 53用户登录业务量测试2小时系统资源图

    5)数据库监控

    数据库执行过程监控正常,符合业务请求变化趋势,如图7- 54所示。

    图7- 54用户登录业务量Mysql资源监控图

    3、更新并发测试结果表

    通过上述测试指标分析,更新用户登录业务量测试结果表如表7- 15所示。

    表7- 15用户登录业务量并发测试结果
    测试项结果属性响应时间业务成功率业务量CPU使用率内存使用率
    用户登录预期结果<=5秒100%2小时5万<=80%<=80%
    实际结果0.131秒100%54961<40%20%
    通过/失败YYNYY

    业务量测试存在一定差异,可进一步测试。

    三、随机购物并发测试结果分析

    1、提取测试指标

    提取随机购物并发测试的目标指标如表7- 16所示。

    2、测试指标分析

    1)响应时间

    测试完成后,根据生成的测试报告,获取随机购物100个并发响应时间如图7- 55所示。

    图7- 55随机购物并发测试响应时间

     通过上图分析,随机购物100个线程并发执行时,平均响应时间分别为:631毫秒、105毫秒、588毫秒、748毫秒、246毫秒、288毫秒、786毫秒、2848毫秒、1934毫秒、2161毫秒、836毫秒、290毫秒、307毫秒,通过这些数据分析,每个请求所消耗的时间均未超过5秒,但90%采样数据中,“填写收货信息”请求响应时间为5395毫秒,严格来说,该请求测试不通过。更新测试目标指标表时可采用90%采样。

    2)Apdex指标

    图7- 56随机购物100并发Apdex指标

    通过上图可以看出,填写收货信息、提交物流及付款方式、进入物流及付款方式设定页面三个请求用户满意度低于0.5,意味系统对这三个请求的响应时间较慢,尤其是收货信息、提交物流及付款方式这两个情况。测试工程师可针对这两个请求,给出性能测试不通过结论。通常而言,最低要求超过0.5,当然项目组可设定具体需求。

    3)业务成功率

    测试结束后,检查系统后台订单信息,100个并发线程,每个线程循环1次,故生成100个订单,且运行过程中没有任何错误。故认为随机购物100并发测试业务成功率为100%

    4)业务量

    线程组设置为100个线程,运行过程中未出现任何异常,满足100个线程并发操作需求。

    5)系统资源使用

    执行过程,通过Jmeter监控得到本次测试系统资源使用情况,如图7- 57所示。

    图7- 57随机购买100并发系统资源监控图

    过上图分析可知,CPU在测试过程中持续值维持在90%以上,有17秒时间几乎达到100%,因此从指标信息判断,本次CPU使用率超过预期80%的目标。

    同时,内存使用率在25秒以后也呈现明显上升趋势,需分析这段时间什么业务导致资源使用率上升。总体内存使用率维持在30%-40%之间,低于预期目标不超过80%,故内存使用率通过。

    基于CPU、内存使用率,分析响应时间图表,如图7- 58所示。

    图7- 58随机购买100并发响应时间图

    通过上图分析,可知“填写收货信息”响应时间持续升高,需测试工程师报告此问题,联合研发同事分析“填写收货信息”涉及哪些具体操作,如是否操作数据库,是否需要大量缓存、是否调用第三方地址编辑控件等,从而确定响应时间升高原因,是否因此导致CPU及内存使用率升高。

    6)数据库监控

    从Mysql数据库SQL语句执行速度来看,符合场景执行设计过程,但SQL中Inserts语句体现不明显,需关注原因,确定是监控本身问题,还是被测对象SQL语句设计问题。

    图7- 59随机购买100并发Mysql数据库资源图

    3、更新并发测试结果表

    通过上述测试指标分析,更新用户登录并发测试结果表如表7- 17所示。

    4、结论

    综合测试数据分析,“填写收货信息”请求响应时间超过5秒,CPU使用率超过90%,故随机购物100并发场景测试不通过。需分析“填写收货信息”涉及哪些操作,导致响应时间变长的原因,是否对CPU及内存使用率造成了影响。

    四、随机购物业务量测试结果分析

    1、提取测试指标

    提取随机购物业务量测试指标如表7- 18所示:

    100个线程持续执行2分钟后,出现大量业务错误,服务器CPU使用率持续维持在100%附近,因此利用100个线程进行2小时的随机购物业务量测试失败。可根据需要,利用折半验证法,验证系统稳定性测试的最佳线程数及服务器资源配置是否合理。

    数据库报错如下:
    
    <b>MySQL server error report:Array
    
    (
    
    [0] => Array
    
    (
    
    [message] => MySQL Query Error
    
    )
    
    [1] => Array
    
    (
    
    [sql] => INSERT INTO `ecshop`.`ecs_order_info` (order_sn, user_id, order_status, shipping_status, pay_status, consignee, country, province, city, district, address, zipcode, tel, mobile, email, best_time, sign_building, postscript, shipping_id, shipping_name, pay_id, pay_name, how_oos, card_message, inv_payee, inv_content, goods_amount, shipping_fee, insure_fee, pay_fee, pack_fee, card_fee, surplus, integral, integral_money, bonus, order_amount, from_ad, referer, add_time, pack_id, card_id, bonus_id, extension_code, extension_id, agency_id, inv_type, tax, parent_id, discount, lastmodify) VALUES ('2017110775867', '2223', '0', '0', '0', 'hzdl00168', '1', '2', '37', '403', '北京东城区', '', '01088888888', '', 'hzdl00168@qq.com', '', '', '', '5', '申通快递', '2', '银行汇款/转帐', '等待所有商品备齐后再发', '', '', '', '1999', '15', '0', '0', '0', '0', '0', '0', '0', '0', '2014.00', '0', '本站', '1510050069', '0', '0', '0', '', '0', '0', '', '0', '0', '', '1510050069')
    
    )
    
    [2] => Array
    
    (
    
    [error] => Duplicate entry '2017110775867' for key 'order_sn'
    
    )
    
    [3] => Array
    
    (
    
    [errno] => 1062
    
    )
    
    )

    系统资源趋势图:

    图7- 60随机购买2小时业务量测试系统资源图

    上述所有场景,如时间、条件、资源允许,测试工程师应当多测试几次,根据平均值输出测试报告。

    展开全文
  • 接口性能测试方案

    千次阅读 2017-05-02 09:58:50
    一、 性能测试术语解释 1. 响应时间 响应时间即从应用系统发出请求开始,到客户端接收到最后一个字节数据为止所消耗的时间。响应时间按软件的特点再可以细分,如对于一个 C/S 软件的响应时间可以细分为网络传输时间...

    原文链接:http://blog.csdn.net/hexieshangwang/article/details/47186507

    一、 性能测试术语解释 
    1. 响应时间 
    响应时间即从应用系统发出请求开始,到客户端接收到最后一个字节数据为止所消耗的时间。响应时间按软件的特点再可以细分,如对于一个 C/S 软件的响应时间可以细分为网络传输时间、应用服务器处理时间、数据库服务器处理时间。另外客户端自身也存在着解析时间、界面绘制呈现时间等。 
    这里写图片描述 
    响应时间主要站在客户端角度来看的一个性能指标,它是用户最关心、并且容易感知到的一个性能指标。 
    2. 吞吐率 
    吞吐率指单位时间内系统处理用户的请求数,从业务角度看,吞吐率可以用每秒请求数、每秒事务数、每秒页面数、每秒查询数等单位来衡量。从网络角度看,吞吐率也可以用每秒字节数来衡量。 
    吞吐率主要站在服务端的角度来看的一个性能指标,它可以衡量整个系统的处理能力。对于集群或者云平台来说,吞吐率指标反映的是服务器集群对外整体能够承受的压力,该指标比用户数更容易对比。 
    备注:吞吐量 = 吞吐率 * 单位时间 
    3. 用户数 
    对于服务器集群或者云平台,几乎都是多用户系统,系统能提供给多少用户正常使用,也是一个非常重要的度量指标。我们把这些用户按照使用系统的时机不同,做如下区分。 
    系统用户数(System Users):指系统能够存储的用户量。 
    在线用户数(Online Users):指用户通过身份确认后,处于能正常使用状态的用户个数。 
    并发用户数(Concurrent users):指在某个时间范围内,同时正在使用系统的用户个数。 
    严格并发用户数(Strictly the number of concurrent users):指同一时刻都操作某个业务的用户数。 
    在性能测试过程中,我们要去模拟实际用户来发请求。但是为了吐服务器产生更大的压力,我们模拟的用户操作和实际的用户操作存在一定的差异(比如模拟的用户请求比实际用户的请求更频繁),而且返种模拟的用户数和实际的用户数也难以相互换算。所以在度量服务器集群能力时,吞吐率指标比用户数指标更实用。 
    二、 性能测试方法及目标 
    1. 性能测试方法 
    1.1 基准测试(Benchmark Testing) 
    基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的测试,目的在于量化响应时间、吞吐率的指标,便于后续比对。 
    方法是做多组不同场景的测试,观察结果,抽取出几个关键数据做好记彔,用于以后进行性能对比和评价。 
    1.2 性能测试(Performance Testing) 
    通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要求。 
    特点: 
    (1) 主要目的是验证系统是否具有系统宣称的能力。 
    (2) 需要事先了解被测系统的典型场景,并具有确定的性能目标。 
    (3) 要求在已确定的环境下运行。 
    1.3 负载测试(Load Testing) 
    通过在被测系统上不断增加压力,直到性能指标,例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。 
    特点: 
    (1) 主要目的是找到系统处理能力的极限。 
    (2) 需要在给定的测试环境下进行,通常也需要考虑被测系统的业务压力量和典型场景,使得测试结果具有业务上的意义。 
    (3) 一般用来了解系统的性能容量,或是配合性能调优使用。 
    1.4 压力测试(Stress Testing) 
    测试系统在一定饱和状态下,例如CPU、内存等在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误。 
    特点: 
    (1) 主要目的是检查系统处于压力情况下是应用的表现。 
    (2) 一般通过模拟负载等方法,使得系统的资源使用达到较高水平。 
    (3) 一般用于测试系统的稳定性。 
    1.5 配置测试(Configuration Testing) 
    通过对被测系统的软/硬件环境的调整,了解各种不同环境对系统性能影响的程度,从而找到系统各项资源的最优分配原则。 
    特点: 
    (1) 主要目的是了解各种不同因素对系统性能影响的程度,从而判断出最值得进行得调优操作。 
    (2) 一般在对系统性能状况有初步了解后进行。 
    (3) 一般用于性能调优和规划能力。 
    1.6 并发测试(Concurrency Testing) 
    通过模拟用户的并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。 
    特点: 
    (1) 主要目的是发现系统中可能隐藏的并发访问时的问题。 
    (2) 主要关注系统可能存在的并发问题,例如系统中的内存泄露、线程锁和资源争用方面的问题。 
    (3) 可在在开发的各个阶段使用,需要相关的测试工具的配合和支持。 
    1.7 可靠性测试(Reliability Testing) 
    通过给系统加载一定的业务压力(例如资源在70%~90%的使用率)的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能稳定运行。 
    特点: 
    (1) 主要目的是验证系统是否支持长期稳定的运行。 
    (2) 需要在压力下持续一段时间的运行。 
    (3) 需要关注系统的运行状况。 
    1.8 失效恢复测试(Failover Testing) 
    针对有冗余备份和负载均衡的系统设计的,可以用来检验如果系统局部发生故障,用户是否能够继续使用系统;以及如果这种情况发生,用户将受到多大程度的影响。 
    特点: 
    (1) 主要目的是验证在局部故障情况下,系统能否继续使用。 
    (2) 还需要指出,当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。 
    (3) 一般来说,只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。 
    2. 性能测试目标 
    概况来说,可分为4个方面: 
    2.1 能力验证 
    在系统测试或验收测试时,我们需要评估系统的能力,衡量系统的性能指标。系统的能力可以是容纳的并发用户数,也可能是系统的吞吐率;系统的性能指标可以是响应时间,也可以选择 CPU、内存、磁盘、网络的使用情况。 
    特点: 
    (1) 要求在已确定的环境下进行。 
    (2) 需要根据典型场景设计测试方案和用例。 
    一般采用的方法是:性能测试、压力测试、可靠性测试、失效恢复测试。 
    2.2 能力规划 
    评估某系统能否支持未来一段时间内的用户增长或是应该如何调整系统配置,使得系统能够满足增长的用户数的需要。 
    特点: 
    (1) 属于一种探索性的测试 
    (2) 可被用来了解系统的性能以及获得扩展性能的方法,例如系统扩容规划。系统容量可以是用户容量,也可能是数据容量,或者是系统的吞吐量(系统的处理能力)。对于集群服务我们更多的是用吞吐率作为容量。 
    方法是①先对各子系统、组件进行性能测试,找出它们之间的最优配比;②然后再通过各环节的水平扩展,计算出整体的扩容机器配比。 
    一般采用的方法是:负载测试、压力测试、配置测试。 
    2.3 性能调优 
    为了更好的发挥系统的潜能,定位系统的瓶颈,有针对性的进行系统优化。 
    方法是在进行系统调优时,我们需要做好基准测试,用以对比性能数据的变化,并反复调整系统软硬件的设置,以使系统发挥最优性能。当然在进行系统优化时,我们会选取关键的指标进行优化,返时可能要牺牲其他的性能指标。如目标是优化响应时间,我们可能选取的策略是以空间换时间,以牺牲内存或扩大缓存为代价,还需要我们在各个性能指标中找到平衡点。 
    一般对系统的调整包括以下3个方面: 
    (1) 硬件环境的调整 
    (2) 系统设置的调整 
    (3) 应用级别的调整 
    一般采用的方法是:基准测试、负载测试、压力测试、配置测试和失效恢复测试。 
    2.4 发现缺陷 
    和其他测试一样,性能测试也可以发现缺陷。特别是严格并发访问时是否存在资源争夺导致的响应时间过慢,或大量用户访问时是否导致程序崩溃。 
    方法是设置集合点,实现严格并发用户访问;或者设置超大规模用户突发访问等这样的性能测试用例进行测试。 
    一般采用的方法是:并发测试。 
    三、 性能需求分析 
    1. 性能需求获取 
    1.1 功能规格说明书 
    1.2 系统设计文档 
    1.3 运营计划 
    1.4 用户行为分析记录 
    2. 性能关键点选取 
    主要从以下4个维度进行选取: 
    2.1 业务分析 
    确定被测接口是否属于关键业务接口或先分析出关键业务以间接获取该业务所访问的接口。 
    2.2 统计分析 
    若接口系统访问行为存在日志分析记录,则直接获取日访问量高的接口;否则根据接口发布类型,选择第3方日志分析工具间接获取。 
    (1) IIS日志分析工具:Log Parser 2.2 + Log Parser Lizard GUI 
    下载地址:http://www.lizard-labs.com/log_parser_lizard.aspx 
    (2) Tomcat日志分析工具:AWStats v7.3 
    下载地址:http://www.awstats.org 
    (3) Nginx日志分析工具:GoAccess v0.9 
    若IIS或Tomcat等接口应用服务器使用Nginx进行负载,则日志访问量要以负载为准,因避免接口在Nginx设置缓存(即未进行透传)而导致统计不正确。 
    下载地址:http://www.goaccess.io

    2.3 技术分析 
    (1) 逻辑实现复杂度高的接口(如判断分支过多或涉及CPU/IO密集型运算等) 
    (2) 对系统(内存、CPU、磁盘IO)及网络IO等硬件资源耗用高的接口 
    备注:若接口因逻辑修改而重构,则需重新分析。 
    2.4 运营分析 
    由于运营推广活动导致日访问突增高的接口。 
    备注:若运营计划调整,则需重新分析。 
    3. 性能指标描述 
    3.1 响应时间 
    在一般情况下,弱交互类接口平均响应时间不超过1秒,强交互类接口平均响应时间不超过200毫秒。 
    3.2 成功率 
    在一般情况下,接口响应成功率需达到99.99%以上。 
    3.3 系统资源 
    若为最佳负载,则系统CPU及内存使用率建议区间[50%,80%],否则建议不超过50%。 
    3.4 处理能力 
    立项申请书明确要求:在XX压力下(并发数)TPS需达到XX或 接口系统可支撑XX万实时在线访问。 
    3.5 稳定性 
    在实际系统运行压力情况下,可稳定运行N*24(一般 N >= 7 )小时。 在高于实际系统运行压力1倍的情况下,可稳定运行12小时。 
    3.6 特性指标 
    例:Java类应用 FullGC 次数 <= 1次/天

    四、 性能测试范围 
    1. 业务范围 
    关键业务功能点描述。 
    2. 设计范围 
    网络接入层、接口层、中间件、存储层等被测组件及拓扑结构描述。 
    五、 并发数计算方法 
    做过一些性能测试的童鞋刚开始比较纠结某个或某一类接口的并发数如何计算,其实并发数可以从用户业务和服务器的2个角度来看。 
    1. 80/X原则 
    适用范围:无限制 
    以一项目为案例,母亲节当天接口服务器访问量分布如下所示,如何计算当天平均并发数和高峰并发数? 
    这里写图片描述 
    通过百度统计平台 http://tongji.baidu.com/ 查看母亲节当天UV曲线分布 与 请求量呈线性关系,如下所示: 
    这里写图片描述 
    采用微积分的思想,将每个时间点视为一个矩形,可以通过求和的方式求出整个分布图的面积,如下所示: 
    这里写图片描述 
    其实每个矩形的长度均为1(1小时),故求面积时只需考虑宽度,即考虑每小时请求量即可。 
    根据80/X原则,找出占据总体面积80%的时间,选择尽可能大的点计算出占据总体面积80%的时间,发现点的个数是7,意味着此时间长度占总时间长度30%,则80/X原则转换成80/30原则,如下所示: 
    这里写图片描述 
    故,平均并发数(每秒平均请求数)= 80% * 日请求量 / 1天 * 30% 
    进而计算出最高峰值与平均并发数的倍数 = 2.25 
    故,高峰并发数(每秒高峰请求数)= 2.25 * 平均并发数 = 
    2.25 * 80% * 日请求量 / 1天 * 30% = 6 * 日请求量 / 1天 
    因UV与请求量曲线分布呈线性关系,日请求量 = 9.25 * 日UV 
    故,高峰并发数 = 6 * 9.25 * 日UV / 1天 = 55.5 * 日UV / 1天 
    2. 公式法 
    适用范围:Web类访问 
    公式(1)计算平均并发用户数:C = n * L / T 
    C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。

    公式(2)计算并发用户数峰值: C’≈ C+3根号C

    C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。 
    这里写图片描述 
    例1: 
    假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。 
    C = 400 * 4 / 8 = 200 
    C’≈ 200 + 3 * 根号200 = 242 
    为了更好地理解上述公式,将其转换为如下公式: 
    公式(3)并发用户数 = 吞吐率 * 场景业务时间 / 单位时间段 
    例2: 
    一个OA系统,1小时内有8000用户登录系统。用户每次登录系统,需启动登录页面,然后输入用户名和密码,进入首页。一般情况下,用户在上述操作过程中需耗时5秒,且要求从点击登录按钮到首页完全展现,需控制在5秒内。 
    分析: 
    吞吐率 = 8000 * 2(整个业务操作需加载2次页面才能完成) 
    场景业务时间 = 5 + 5 = 10 秒 
    单位时间段 = 1小时 = 3600 秒 
    并发用户数(登录场景) = (8000 * 2)* 10 / 3600 = 45 
    通过以上方法得到业务并发数后,我们可以进一步分析业务访问了哪些接口,我们只要模拟这些接口调用方式和调用时序就行了。 
    有时我们需要计算某一个或某一类接口的并发数,我们可以按如下步骤进行分析计算: 
    (1) 梳理出被测接口被访问的业务场景和每个业务场景访问的次数 
    (2) 通过上述方法计算出业务场景的并发用户数 
    接口并发数 = 场景1 并发用户数 * 业务场景接口调用次数1 + 场景2并发用户数 * 接口调用次数2 + …

    假如一个系统需支撑10万在线用户数访问,如何通过性能需求分析来计算并发用户数?大家可以通过以上内容学习,独立思考下?

    六、 性能测试用例与场景

    1. 脚本模板 
      这里写图片描述         
    2. 场景模板 
      这里写图片描述 

    七、 性能测试工具选择 
    1. 数据建模工具 
    DataFactory是一种强大的数据产生器,它允许开发人员和QA很容易产生百万行有意义的正确的测试数据库,该工具支持DB2、Oracle、 Sybase、SQL Server数据库,支持ODBC连接方式,无法直接使用MySQL数据库,可间接支持。 
    2. 脚本开发工具 
    (1) 若考虑脚本运行效率,则可考虑底层开发语言C或支持异步通信的语言JS,我们可以分别选择:Loadrunner 或 Node.js 的IDE环境进行开发。 
    (2) 若考虑脚本开发效率,则可考虑代码复用性,可以选择面向对象语言C#或Java,为此我们可以分别选择:VS2008及以上版本 + 对应LR.NET控件 或者 Eclipse4.0及以上版本 + JDK1.7及以上版本。 
    HTTP、Socket等协议接口性能测试脚本开发过程,请详见附件: 
    HTTP接口性能测试之脚本开发与性能问题分析.pdf 
    利用LR.Net控件完成性能测试脚本编写方法.pdf 
    node.js学习入门手册.pdf 
    3. 压力模拟工具 
    (1) 若为Java类接口且单机并发数控制在500内,则可选择Jmeter或者 Loadrunner。 
    (2) 若为WebService类接口且单机并发数控制在500内,则可选择SoapUI或者Loadrunner。 
    (3) 若单机并发数超过500且控制在5000内,则可选择Loadrunner。 
    (4) 若单机并发数超过5000,则建议采用负载集群,即采用“中控(Control Center)+ 多机部署(Load Generator)”方案。 
    4. 性能监控工具 
    4.1 监控工具 
    无论Windows或Linux平台,一般存在的是一个或一组进程实例,我们可以选择Loadrunner 或 Nmon 来监控。有时为了获取被测应用的一些特性指标,可以选择被测组件自带的性能工具集或监控系统。常见应用服务器监控工具推荐如下: 
    这里写图片描述 
    4.2 监控平台 
    监控机器主要对被测集群服务器的服务或资源使用情况进行监控,比如各种开源的监控工具,MRTG:流量监控;CACTI:流量预警,性能报告Smokeping:IDC 质量监控;综合监控:Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等,如下所示: 
    这里写图片描述 
    4.3 第三方监控云服务(APM) 
    APM提供端到端应用性能管理软件及应用性能监控软件解决方案,包含移动,浏览器,应用,基础设施,网络,数据库性能管理等,支持Java、.NET、PHP、Ruby、Python、Node.js、iOSAndroidHTML5等应用性能监控管理,主流云服务包括听云、OneAPM等,如下所示: 
    这里写图片描述

    八、 性能测试结果分析 
    1. 指标分析 
    性能测试的指标可分为产品指标和资源指标两类。对测试人员而言,性能测试的需求来自于用户、开发、运维的三方面。用户和开发关注的是与业务需求相关的产品指标,运维人员关注的是与硬件消耗相关的资源指标。 
    这里写图片描述 
    (1) 从用户角度关注的指标 
    用户关注的是单次业务相关的体验效果,譬如一次操作的响应快慢、一次请求是否成功、一次连接是否失败等,反映单次业务相关的指标包括: 
    a.成功率b.失败率c.响应时间 
    (2) 从开发角度关注的指标 
    开发人员更关注的是系统层面的指标。 
    a.容量:系统能够承载的最大用户访问量是多少?系统最大的业务处理量是多少? 
    b.稳定性:系统是否支持7*24小时(一周)的业务访问。 
    (3) 从运维角度关注的指标 
    运维人员更关注的是硬件资源的消耗情况。 
    这里写图片描述 
    以上说明了测试人员在选择指标时需站在用户角度去思考,另外为了后续能够更好地分析问题,更需掌握与被测组件特性或运行原理相关的性能指标。

    举例来说,通常接口系统均会直接或间接地访问数据库层介质(如Mysql、Oracle、SQLServer等),此时我们需考虑由接口系统产生压力下存储介质的性能情况,通常我们会选择分析指标如下: 
    (1) 连接数(Connections) 
    (2) 每秒查询数/每秒事务数(QPS/TPS) 
    (3) 每秒磁盘IO数(IOPS) 
    (4) 缓存命中率(Buffer Hits) 
    (5) 每秒发生的死锁数(Dead Locks/sec) 
    (6) 每秒读/写字节数(Read/Write Bytes/sec) 
    对于Windows或Linux平台具体指标监控及分析方法,请详见附件: 
    《Windows操作系统性能监控工具和指标分析V1.0》.pdf 
    《Linux操作系统性能监控分析手册V1.0》.docx 
    2. 建模分析 
    2.1 理发店模型 
    这里写图片描述 
    图中展示的是1个标准的软件性能模型。在图中有三条曲线,分别表示资源的利用情况(Utilization,包括硬件资源和软件资源)、吞吐量(Throughput,这里是指每秒事务数)以及响应时间(Response Time)。图中坐标轴的横轴从左到右表现了并发用户数(Number of Concurrent Users)的不断增长。 
    在这张图中我们可以看到,最开始,随着并发用户数的增长,资源占用率和吞吐量会相应的增长,但是响应时间的变化不大;不过当并发用户数增长到一定程度后,资源占用达到饱和,吞吐量增长明显放缓甚至停止增长,而响应时间却进一步延长。如果并发用户数继续增长,你会发现软硬件资源占用继续维持在饱和状态,但是吞吐量开始下降,响应时间明显的超出了用户可接受的范围,并且最终导致用户放弃了这次请求甚至离开。 
    根据这种性能表现,图中划分了三个区域,分别是Light Load(较轻的压力)、Heavy Load(较重的压力)和Buckle Zone(用户无法忍受并放弃请求)。在Light Load和Heavy Load 两个区域交界处的并发用户数,我们称为“最佳并发用户数(The Optimum Number of Concurrent Users)”,而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数(The Maximum Number of Concurrent Users)”。 
    当系统的负载等于最佳并发用户数时,系统的整体效率最高,没有资源被浪费,用户也不需要等待;当系统负载处于最佳并发用户数和最大并发用户数之间时,系统可以继续工作,但是用户的等待时间延长,满意度开始降低,并且如果负载一直持续,将最终会导致有些用户无法忍受而放弃;而当系统负载大于最大并发用户数时,将注定会导致某些用户无法忍受超长的响应时间而放弃。所以我们应该保证最佳并发用户数要大于系统的平均负载。 
    2.2 压力变化模型 
    这里写图片描述 
    随着单位时间流量的不断增长,被测系统的压力不断增大,服务器资源会不断被消耗,TPS 值会因为这些因素而发生变化,而且符合一定的规律。

    图中: 
    a 点:性能期望值 
    b 点:高于期望,系统资源处于临界点 
    c 点:高于期望,拐点 
    d 点:超过负载,系统崩溃 
    2.3 容量计算模型

    这里写图片描述 
    以一网站性能测试为案例: 
    1. 通过分析运营数据,可以知道当前系统每小时处理的PV数 
    2. 通过负载测试,可以知道系统每小时最大处理的PV数

    即整理得

    系统每小时PV处理剩余量 = 系统每小时最大处理的PV数 — 系统每小时处理的PV数

    假设该网站用户负载基本呈线性增长,现有系统用户数为70万,根据运营推广计划,1年内该网站发展用户将达到1000万,即增长了14倍。即整理得:

    系统每小时PV处理增加量 = 当前系统每小时处理的PV数 * 14 — 当前系统每小时处理的PV数

    每天系统负载增加率 = 100% / 365 = 2.74 % (备注:此处将未来系统用户数达到1000万的负载定义为 100% )

    系统每天PV处理增加量 = 系统每小时PV处理增加量 * 每天系统负载增加率 * 24

    所以,我们可以知道在正常负载条件下:

    系统可支持正常运行天数 = 系统每小时PV处理剩余量 * 24 / 系统每天PV处理增加量

    假设该网站后续部署升级天数已知,这样我们可以知道提前升级的天数:

    系统可支持正常运行天数 — 部署升级天数。 
    九、 性能测试通过标准 
    1. 所有计划的测试已经完成。 
    2. 所有计划收集的性能数据已经获得。 
    3. 所有性能瓶颈得到改善并达到设计要求。 
    十、 性能测试书籍推荐

    这里写图片描述

    这里写图片描述

    这里写图片描述

    这里写图片描述 
    十一、 性能测试报告模板 
    详见附件: 
    性能测试报告模板.doc

    展开全文
  • Jmeter接口测试+压力测试

    万次阅读 多人点赞 2017-05-14 14:01:50
    jmeter是apache公司基于java开发的一款开源压力测试工具,体积小,功能全,使用方便,是一个比较轻量级的测试工具,使用起来非常简单。...  jmeter可以做接口测试和压力测试。其中接口测试的简单操作
  • Jmeter接口压力测试学习总结 一.创建测试用例 Jmeter主界面: 1.添加线程组 测试计划 (右键->添加->Threads(Users)->线程组),修改线程组名称为“登录”,可添加多个线程组,设置线程数;Ramp-Up ...
  • 什么是压力测试压力测试是给软件不断加压,强制其在极限的情况下运行,观察它可以运行到何种程度,从而发现性能缺陷,是通过搭建与实际环境相似的测试环境,通过测试程序在同一时间内或某一段时间内,向系统...
  • Jmeter接口压力测试

    千次阅读 2018-03-28 16:21:00
    Jmeter是Apache组织开发的基于Java的压力测试工具,是一个开源软件,它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能,可以使用它做性能的图形分析或大并发负载测试...
  • JMeter接口压力测试

    2020-12-24 07:46:17
    压力测试前的准备 1、压力测试分两种场景:一种是单场景,压一个接口的;第二种是混合场景,多个有关联的接口 2、压测时间,一般场景运行1分钟。如果是疲劳测试,可以压几个小时或是一天,根据实际情况来定。 压测...
  • 摘要  随着通信业的发展,百兆以太...本文结合作者在以太网领域多年的测试经验,介绍了100BASE-TX接口指标测试方法和测试仪器的选用,并将使用Tektronix公司CSA7404通信信号分析仪进行测试所获得的图形供大家参考。
  • 压力测试中的指标概念

    千次阅读 2021-02-18 15:38:37
    压力测试中的指标1 压力测试中的指标1.1 TPS1.2 QPS1.3 平均处理时间(RT)1.4 并发用户数(并发量)1.5 换算关系1.6 TPS和QPS的区别2 压力测试方法3 名称概念解释1. QPS2. TPS3. RPS 1 压力测试中的指标 1.1 TPS TPS ...
  • 背景 小A:小B,最近调你的接口老是超时呀,8秒都还没返回结果,是不是有性能问题呀! 小B :我看看~~ ...本着对自己写出来的东西负责,上线之前,我们都应该对自己的接口进行一个简单的压力测试。 其实做...
  • Jmeter基础篇(01):如何进行post接口压力测试

    千次阅读 多人点赞 2019-04-10 21:04:55
    目前网络上有很多很多Jmeter的压力测试使用指南,但是在实际使用过程中,很多朋友会遇到许多并...博主最近基于事业部当前所负责的项目,对其做了一个简单的接口压力测试。今天就以博主所测试的实际项目为例,为大家...
  • 本文就讲述使用Loadrunner对此类接口进行压力测试并记录相关的性能指标数据: 一.安装Loadrunner 本次测试过程使用Loadrunner 11.0版本。 二.部署环境 1.接口服务器一台; 2.用于运行Loadrunner的压力测试机...
  • 接口测试 1.定义:接口测试测试系统组件间接口的一种测试接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑...
  • 使用jmeter进行api接口压力测试

    万次阅读 多人点赞 2018-06-26 15:16:47
    压力测试的工具由挺多的,但看了其他人的文章介绍,还是选了jmeter,开源、免费啊, 下载 下载地址: https://jmeter.apache.org/download_jmeter.cgi 环境配置 下载后解压zip到任意目录,然后配置环境变量...
  • 前段时间只是看了小强的视频,跟着视频做一些实验,这周有个项目需要做压力测试,我便做个全程记录,以后自己用到也回来看看,毕竟很长时间不做就忘记了。 业务场景 可知某系统A目前是2台机器承受10W用户,...
  • 使用jemeter进行压力测试关注的指标

    千次阅读 2020-07-05 22:37:57
    压测过程出现性能瓶颈,若压力机任务管理器查看到的cpu、网络和cpu都正常,未达到90%以上,则可以说明服务器有问题,压力机没有问题。 影响性能考虑点包括:数据库、应用程序、中间件(tomact、Nginx)、网络和操作...
  • jmeter(压力测试指标分析

    千次阅读 2019-09-17 10:01:54
    压力测试分两种场景:一种是单场景,压一个接口的;第二种是混合场景,多个有关联的接口。 压测时间,一般场景都运行10-15分钟。如果是疲劳测试,可以压一天或一周,根据实际情况来定。 压测任务需求的确认 ...
  • 性能测试/压力测试指标 ** 服务端性能测试 来源:在产品的需求文档里,提供给测试,取决服务多少量的客户,这是产品的需求!! TPS transaction per second 服务端每秒处理请求的数量 最直观的反映了系统的处理...
  • 压力测试指标(QPS、TPS、PV、RT)

    千次阅读 2021-03-04 10:21:56
    QPS(Queries Per ... 参考: 压测指标:https://blog.csdn.net/qq_31749835/article/details/103969076 压力测试指标:https://cloud.tencent.com/developer/news/360223 QPS,TPS,吞吐量,响应时间详解及关系:...
  • 2. 性能测试:在一定负荷压力下,系统的响应时间,吞吐量,稳定性系统的可扩展性的性功能指标 流程: 评估----》加压---》bug瓶颈---》分析调优---》长时间跑(稳定性) 3.学习性能: 测试思维方法,分析方法 4...
  • 使用Jmeter做接口压力测试-实战

    千次阅读 2018-06-24 22:48:55
    缘由:前段时间只是看了小强的视频,跟着视频做一些实验,这种学习方式总会给人一种 ‘我学的是假Jmeter’ 的错觉,这周有个项目需要做压力测试,我便做个全程记录,以后自己用到也回来看看,毕竟很长时间不做就忘记...
  • locust接口压力测试

    2019-04-10 18:41:42
    今天临时接了一个http协议的接口压测任务,就一个接口,想着也能熟悉下locust,顺便对比jmeter无GUI的区别,就用locust进行了压测,操作步骤和命令如下: 第一种写法: 1,监听端口命令 ps -ef |grep viewers.py ...
  • 记一次接口压力测试与性能调优

    千次阅读 2018-06-18 21:57:19
    压力测试过程中,我们重点关注TPS、GC次数、CPU占用率和接口响应时间等指标。 二、测试过程 完成项目部署后,我们开始编辑jemeter测试脚本,设置压力测试的标准为200个并发线程,在10秒内全部启动,持续压测...
  • 记一次Grpc接口压力测试&性能调优

    千次阅读 2018-09-20 18:09:48
    如果在压测过程中,压力始终上不去,可以考虑是施压机器并发上不去,或者被压机器请求处理不过来。 施压上不去或者被压机器请求处理不过来,是因为机器CPU瓶颈?内存瓶颈?端口数量瓶颈?逐步排查定位。 类似于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 25,569
精华内容 10,227
关键字:

接口压力测试指标

友情链接: verlet-js-master.zip