性能需求分析

需求分析是个繁杂过程,它并非我们想象的那么简单,而性能测试需求除了要对系统的业务非常了解,还需要有深厚性能测试知识。才能够挖掘分析出真正的性能需求。

1、如何获得有效的需求

1.1、客户方提出

客户方能提出明确的性能需求,说明对方很重视性能测试,这样的企业一般是金融、电信、银行、医疗器械等;他们一般对系统的性能要求非常高,对性能也非常了解。提出需求也比较明确。
曾经有一个银行项目,已经到最后的性能测试极端,因为数据库设计不合理,导致性能出现很大的问题,最终不得不把整合项目作废,对于这样的项目,其实从分析设计阶段就应该考虑系统的性能问题。性能测试也一样,对于某些项目来说越早进行越好。当然,前期的性能测试为单元性能测试、接口性能测试,有别系统性能测试。

2、根据历史数据分析

对于一些面向用户的独特产品,比较难定位市场的大小,可以先上一运营一段时间,通过运营可以搜集客户资料,比如,每月、每星期、每天的峰值业务量是多少。用户以什么样的速度在递增中。用户对系统的哪些功能模块使用的最多,他们所点的比例等等。收集到这些数据之后,我们就可评估系统的系统需求指标,从而进行性能测试。

3、需求分析与定位

这里根据前期的需求分析与定位,来分析确定系统性能指标。例如某省幼儿园管理系统。统计全省有多少家幼儿园,系统的使用时间为幼儿到校之后,管理人员对幼儿的到校情况进行录入,以及幼儿的午饭,放学情况的录入时间。经过与需求人员交流分析也能得到比较明确的性能指标。

4、参考历史项目或其它同行业的项目

如果公司之前有类似的项目经验,根据项目大小及上次性能测试的一些指标。从根据项目的规模可以制定出相应的性能指标。
即使本公司没有类似的项目,但其它公司有类似的项目,例如做IPTV或者DVB计费系统的测试,可以参考电信计费系统的需求——虽然不能完全照搬数据,但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些,应该考虑到的情况有哪些种。

5、参考其它资料数据

如果你做的是非常独特的产品,市场上没有此类型的产品,而且需求及市场也难以估计,那么只能从与产品相关的资料中寻找痕迹了。不过,相信这样不确定性的产品,老板要承担的风险也是挺大的。

需要说明的是,我上面介绍的方面并非是独立的,可以综合的使用,你可以根据客户提出的指标,再根据历史数据以及参考同类型项目来进行。这样可以更确定你的性能指标是客户(或自己)真正需要的、最符合项目需求的。

2、性能测试点的选取

*  发生频率非常高的(例如:某核心业务系统中的登录、收发等业务,它们在每天的业务总量中占到90%以上)
*  关键程度非常高的(产品经理认为绝对不能出现问题的,如登录,扫码,支付等)
*  资源占用非常严重的(导致磁盘I/O非常大的,例如某个业务进行结果提交时需要向数十个表存取数据,或者一个查询提交请求时会检索出大量的数据记录)

3、常见性能需求

1、接口的响应速度达到300ms以下。
2、系统服务支持50万个在线用户
3、接口成功率达到99.5%以上。
4、在100个并发用户的高峰期,系统的基本功能,处理能力至少达到10TPS
5、这个系统能否支撑200万的vu(每天登录系统的人次)          vu----Virtual user(虚拟用户)

"不成文"的性能需求指标:
80/20原则:又称帕累托效应,比如,某一些系统一天中80%的访问量集中在20%的时间内。

4、下面来分析某移动支付的需求:

按照2018年日交易笔数的目标为1000万笔:

如何得到每秒的交易笔数?

一: 严格的根据2/8原则  ,80%的订单集中在20%的时间生成。

集中订单交易数:  10000000*80%=8000000笔

集中发送的时间:24*20%=4.8小时=17280秒

每秒生成的订单数:8000000/17280=462.9笔/秒

二:另外的200W交易笔数请求分布在另外的23个小时内,因为考虑到半夜之后基本没什么请求量,假设另外的200W次请求分布在10:00-24:00,那么我们另外一个指标是 2000000/14/3600 = 39.68 (稳定支持这样的TPS)

5、性能测试场景设计

峰值场景设计: 设计符合业务场景的高压力场景,比如大量并发集中在半小时-1小时内

稳定场景设计: 8-10小时的长时间稳定压力场景

性能瓶颈压测场景: 逐步增加压力,寻找业务请求瓶颈(适用于没有业务指标,技术优化类)

秒杀类超大并发场景设计: 测试秒杀场景

6、性能测试通过标准

达到目标预期

Jmeter性能工具的运用

上一节中,我们根据业务量算出了TPS

1)测试目标接口:扫码接口

2)测试目的是该接口在负载达到462.9TPS 时的响应时间。

TPS 解释

  TPS:Transactions Per Second(每秒传输的事物处理个数),即服务器每秒处理的事务数。

包括了

1)用户请求服务器

2)服务器自己的内部处理

3)服务器返回给用户

  为了达成预期的测目的,需要需要在jmeter中建立一个测试计划。因为本次测试仅要求完成对目标接口的请求,因此只需要使用HTTP Request Sampler 即可。

建立测试计划

  启动jmeter后,jmeter会自动生成一个空的测试计划,用户可以基于该测试计划建立自己的测试计划。

添加线程组

  一个性能测试请求负载是基于一个线程组完成的。一个测试计划必须有一个线程组。测试计划添加线程组非常简单。在测试计划右键弹出下拉菜单(添加-->Threads(Users)--->线程组)中选择线程组即可。

  jmeter中 每个测试计划至少需要包含一个线程组,当然也可以在一个计划中创建多个线程组,那么多个线程组之间又会怎样的顺序执行(串行还是并行)?在测试计划下面多个线程是并行执行的,也就是说这些线程组是同时被初始化并同时执行线程组下的Sampler的。

  线程组主要包含三个参数:线程数、准备时长(Ramp-Up Period(in seconds))、循环次数。

线程数:虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。

准备时长: 设置的虚拟用户数需要多长时间全部启动。如果线程数为20 ,准备时长为10 ,那么需要10秒钟启动20个线程。也就是每秒钟启动2个线程。

循环次数:每个线程发送请求的次数。如果线程数为20 ,循环次数为100 ,那么每个线程发送100次请求。总请求数为20*100=2000 。如果勾选了“永远”,那么所有线程会一直发送请求,一到选择停止运行脚本。

  设置合理的线程数对于能否达到测试目标有决定性的影响。在本例中,要求得到接口在462.9TPS 负载情况下的响应时间,如果如果线程数量设置的过小,则很可能无法达到设定的TPS要求。另外,设置合理的循环次数也很重要,除了上面介绍的固定循环次数与永远外;也可以灵活的选择设定测试运行时间。勾选“调度器”,进行调度器配置。

添加HTTP请求

  添加完成线程组后,在线程组上右键菜单(添加--->Sampler--->HTTP请求)选择HTTP请求。对于jmeter来说,取样器(Sampler)是与服务器进行交互的单元。一个取样器通常进行三部分的工作:

1、向服务器发送请求

2、记录服务器的响应数据

3、记录相应时间信息

  一个HTTP请求有着许多的配置参数,下面将详细介绍:

名称:本属性用于标识一个取样器,建议使用一个有意义的名称。

注释:对于测试没有任何作用,仅用户记录用户可读的注释信息。

服务器名称或IP :HTTP请求发送的目标服务器名称或IP地址。

端口号:目标服务器的端口号,默认值为80,https默认端口为443

协议:向目标服务器发送HTTP请求时的协议,可以是http或者是https ,默认值为http 。

方法:发送HTTP请求的方法,可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。

Content encoding :内容的编码方式,默认值为iso8859

路径:目标URL路径(不包括服务器地址和端口)

自动重定向:如果选中该选项,当发送HTTP请求后得到的响应是302/301时,JMeter 自动重定向到新的页面。

Use keep Alive : 当该选项被选中时,jmeter 和目标服务器之间使用 Keep-Alive方式进行HTTP通信,默认选中。

Use multipart/from-data for HTTP POST :当发送HTTP POST 请求时,使用Use multipart/from-data方法发送,默认不选中。

同请求一起发送参数 : 在请求中发送URL参数,对于带参数的URL ,jmeter提供了一个简单的对参数化的方法。用户可以将URL中所有参数设置在本表中,表中的每一行是一个参数值对(对应RUL中的 名称1=值1)。

同请求一起发送文件:在请求中发送文件,通常,HTTP文件上传行为可以通过这种方式模拟。

从HTML文件获取所有有内含的资源:当该选项被选中时,jmeter在发出HTTP请求并获得响应的HTML文件内容后,还对该HTML进行Parse 并获取HTML中包含的所有资源(图片、flash等),默认不选中,如果用户只希望获取页面中的特定资源,可以在下方的Embedded URLs must match 文本框中填入需要下载的特定资源表达式,这样,只有能匹配指定正则表达式的URL指向资源会被下载。

用作监视器:此取样器被当成监视器,在Monitor Results Listener 中可以直接看到基于该取样器的图形化统计信息。默认为不选中。

Save response as MD5 hash? :选中该项,在执行时仅记录服务端响应数据的MD5值,而不记录完整的响应数据。在需要进行数据量非常大的测试时,建议选中该项以减少取样器记录响应数据的开销。

  在这里我们添加一个HTTP请求,用于对扫码接口发送请求。

设置TPS限制

  本次性能测试的需求中提到测试的目的是“扫码支付接口在负载达到462.9TPS时的响应时间”,因此需要控制向扫码支付发送请求的负载为462.9TPS。

  一种可行的方法是逐步调整测试计划中的线程计算的数量以及为取样器(Sampler)添加定时器(Timer),以使HTTP取样器发出的请求的TPS保持在462.9个左右。但这种方法耗时耗力,需要经过多次尝试才能达到;另一方法,完全通过设置定时器来控制TPS,一旦取样器的响应时间发生改变(网络环境发生改变),就需要重新调整定时器的等待时间。

  Jmeter提供了一个非常有用的定时器,称为Constant Throughput Timer (常数吞吐量定时器),该定时器可以方便地控制给定的取样器发送请求的吞吐量。

  右键点击fnng.cnblogs.com ,弹出菜单(添加--->定时器--->Constant Throughput Timer)选择Constant Throughput Timer

Constant Throughput Timer 的主要属性介绍:

名称 :定时器的名称

Target throughput(in samples per minute):目标吞吐量。注意这里是每分钟发送的请求数,因此,对应测试需求中所要求的462.9TPS ,这里的值应该是27774 。

Calculate Throughput based on :有5个选项,分别是:

  This thread only :控制每个线程的吞吐量,选择这种模式时,总的吞吐量为设置的 target Throughput 乘以该线程的数量。

  All active threads : 设置的target Throughput 将分配在每个活跃线程上,每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。

  All active threads in current thread group :设置的target Throughput将分配在当前线程组的每一个活跃线程上,当测试计划中只有一个线程组时,该选项和All active threads选项的效果完全相同。

  All active threads (shared ):与All active threads 的选项基本相同,唯一的区别是,每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。

  All cative threads in current thread group (shared ):与All active threads in current thread group 基本相同,唯一的区别是,每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。

  如上图,该元件仅作用于扫码接口 ,设置定时器的Target throughput为27774/分钟(462.9TPS),设置Calculate Throughput based on 的值为All active threads 。

  当然,Constant Throughput Timer只有在线程组中的线程产生足够多的request 的情况下才有意义,因此,即使设置了Constant Throughput Timer的值,也可能由于线程组中的线程数量不够,或是定时器设置不合理等原因导致总体的TPS不能达到预期目标。

添加监听器(Listener)

  脚本的主要部分设置完成后,需要通过某种方式获得性能测试中的测试结果,在本例中,我们关心的是请求的响应时间。

  Jmeter 中使用监听器元件收集取样器记录的数据并以可视化的方式来呈现。Jmeter有各种不同的监听器类型,因为上HTTP请求,我们可在添加聚合报告,更为直观的查看测试结果。

  添加聚合报告,右键点击线程组,在弹的菜单(添加--->监听器--->聚合报告)中选择聚合报告。

运行脚本

  添加完成聚合报告后,我们来运行脚本,稍后介绍聚合报告的参数。

  在运脚本之前,我们来查看一下,各个元件的参数设置:

---------------------------------------------------------------

线程组:

线程数:20

准备时长: 10

循环次数:10

---------------------------------------------------------------

HTTP请求:

名称:fnng.cnblogs.com。

服务器名称或IP :fnng.cnblogs.com

端口号:80

Implementation : java

协议: http

方法: POST

路径:/

---------------------------------------------------------------

常数吞吐量定时器:

Target throughput(in samples per minute):1200.0

Calculate Throughput based on :All active threads

---------------------------------------------------------------

点击工具栏上的运行按钮,或者点击菜单栏“ 运行--->启动 ” 或者使用快捷键ctrl+r 来运行程序。

聚合报告分析

查看聚合报告的运行结果:

性能测试脚本的编写

一、http请求的脚本编写

以线上打款接口为例:

1、启动jmeter,建立一个测试计划。

启动:打开jmeter文件夹,bin文件→jmeter.bat(Windows执行文件)文件,就可以启动jmeter了

2、添加用户定义参数,定义IP和端口号

3、添加Http信息头管理器

4、添加Http Cookie管理器

5、添加逻辑控制器及登录http接口的请求

6、添加线上打款Http接口的请求

7、添加聚合报告查看结果

二、Java请求的脚本编写

JMETER-性能测试相关推荐

  1. Jmeter性能测试 入门

    Jmeter性能测试 入门 原文:Jmeter性能测试 入门 Jmeter是一款优秀的开源测试工具, 是每个资深测试工程师,必须掌握的测试工具,熟练使用Jmeter能大大提高工作效率. 熟练使用Jme ...

  2. jmeter性能测试入门简介

    Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件.相比Loadrunner而言,JMeter小巧轻便且免费,逐渐成为了主流的性能测试工具,是每个测试人员都必须要掌握的工 ...

  3. JMeter性能测试的基础知识和个人理解

    JMeter性能测试的基础知识和个人理解 1. JMeter的简介   JMeter是Apache组织开发的开源项目,设计之初是用于做性能测试的,同时它在实现对各种接口的调用方面做的比较成熟,因此,常 ...

  4. Jmeter性能测试-GC相关

    2019独角兽企业重金招聘Python工程师标准>>> https://www.cnblogs.com/danqiu/p/6009016.html Jmeter性能测试-GC相关 1 ...

  5. spring cloud微服务间限流,使用jMeter性能测试高并发

    有关网关限流方式查看上一篇博客:spring cloud网关(zuul)限流,使用jMeter性能测试高并发 在网关限流后,有可能有些微服务与网关山的限流不一致,比如网关限流100QPS,而微服务只能 ...

  6. spring cloud网关(zuul)使用RateLimiter限流,使用jMeter性能测试高并发

    原理:使用令牌桶. 固定时间内产生一定数量的令牌,比如设置1秒产生50个令牌,但是1秒内出现了100个用户并发访问,此时只有50个用户能拿到令牌,剩余50直接阻挡,被限流. 核心代码,zuu编写PRE ...

  7. JMeter性能测试,完整入门篇(自己做测试了)

    原文转自:https://blog.csdn.net/lovesoo/article/details/78579547 Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件 ...

  8. JMeter性能测试工具简介

    JMeter性能测试工具简介 本文简单介绍了什么是性能测试,以及如何通过Jmeter工具开展性能测试. Jmeter里面的常用元素包含线程组,取样器,监听器,配置元素和一些其他元素 Jmeter原理 ...

  9. jmeter性能测试_JMeter性能测试,接口测试,最全的JMeter资料,共计3.16G

    前言 JMeter是Apache组织开发的基于Java的压力测试工具.JMeter 可以用于对服务器.网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能.另外,JMeter能够对 ...

  10. Jmeter性能测试云平台搭建

    本篇文章主要讲解Jmeter性能测试云平台搭建,这是我们在进行DevOps云平台中性能测试一部分,后期结合docker容器技术进行集群的动态扩展.

最新文章

  1. 值得收藏的45个Python优质资源(附链接)
  2. ASP.NET Core的Kestrel服务器
  3. [架构]--高并发问题及解决方案
  4. mysqlbinlog: [ERROR] unknown variable ‘default-character-set=utf8mb4‘
  5. rabbitmq学习——队列
  6. 初探EntityFramework——来自数据库的Code First
  7. 统计学习方法读书笔记1-统计学习方法概论
  8. amazeui学习笔记--js插件(UI增强4)--下拉组件Dropdown
  9. html推箱子过关检测函数,HTML5推箱子实现
  10. 重整国家资产负债表的核心是谁来买单
  11. 1x pcie 速度_PCIe传输速率计算方法
  12. 在自行下载的背景图片上写字
  13. linux 内存block读取6,Linux硬盘 和文件系统维护
  14. python实战| 爬取虎牙高质量小姐姐私房照!
  15. 医院招聘sass管理软件解决方案分析(2)
  16. 【重识云原生】计算第2.2节——主流虚拟化技术之VMare ESXi
  17. 微信api接入验证的坑!!!
  18. php转换时间戳的一些方法
  19. 列变位法解密-2016百度之星 - 测试赛(热身,陈题)
  20. RPA机器人流程自动化(Robotic process automation)

热门文章

  1. window10 安装语言包出现“很抱歉,我们无法安装此功能。你可以稍后重试。错误代码: 0x80070422”
  2. hadoop3.3.0 编译环境搭建
  3. 海润与联合“罗生门”升级
  4. java考试成绩平均计算_Java计算平均成绩
  5. DNS解析记录中的CNAME与URL重定向(301/302)区别
  6. java fastdfs集成图片压缩与水印
  7. 《象与骑象人听书笔记》
  8. 计算机显示windows update,我的电脑显示“系统管理员已禁用Windows Update”这要如何解决...
  9. C#oop体检套餐管理系统
  10. 京东助手抢购-购买口罩教程