大家好,我是IT修真院北京分院的学员,一枚正直善良的JAVA程序员。
今天给大家分享一下,如何用jmeter做压力测试
1.背景介绍:
什么是压力测试?
Nginx(engine x) 是一个高性能的HTTP和反向代理服务器。
什么是jmeter?
Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试,它最初被设计用于Web应用测试,但后来扩展到其他测试领域。 它可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器, 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。
2知识剖析
1.评估系统的能力
2.识别体系中的弱点
3.系统调优
4.验证稳定性,可靠性
3.常见问题
如何对web项目进行简单的压力测试
4.解决方案:
使用jmeter
1、线程组:代表一定数量的并发用户,它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义,它被线程组包含。可以在“测试计划->添加->线程组”来建立它,然后在线程组面板里有几个输入栏:线程数、Ramp-Up Period(in seconds)、循环次数,其中Ramp-Up Period(in seconds)表示在这时间内创建完所有的线程。如有8个线程,Ramp-Up = 200秒,那么线程的启动时间间隔为200/8=25秒,这样的好处是:一开始不会对服务器有太大的负载。线程组是为模拟并发负载而设计。
2、取样器(Sampler):模拟各种请求。所有实际的测试任务都由取样器承担,存在很多种请求。如:HTTP 、ftp请求等等。
3、监听器:负责收集测试结果,同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据(吞吐量、KB/S……)等。
4、断言:用于来判断请求响应的结果是否如用户所期望,是否正确。它可以用来隔离问题域,即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
5、定时器:负责定义请求(线程)之间的延迟间隔,模拟对服务器的连续请求。
6、逻辑控制器:允许自定义JMeter发送请求的行为逻辑,它与Sampler结合使用可以模拟复杂的请求序列。
7、配置元件维护Sampler需要的配置信息,并根据实际的需要会修改请求的内容。
8、前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置,后置处理器则常常用来处理响应的数据。
聚合报告参数详解
Label:每个 JMeter 的 element(例如 HTTP Request)都有一个 Name 属性,这里显示的就是 Name 属性的值
#Samples:表示你这次测试中一共发出了多少个请求,如果模拟10个用户,每个用户迭代10次,那么这里显示100
Average:平均响应时间——默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也可以以Transaction 为单位显示平均响应时间
Median:中位数,也就是 50% 用户的响应时间
90% Line:90% 用户的响应时间
Note:关于 50% 和 90% 并发用户数的含义
Min:最小响应时间
Max:最大响应时间
Error%:本次测试中出现错误的请求的数量/请求的总数
Throughput:吞吐量——默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 LoadRunner 的 Transaction per Second 数.
KB/Sec:每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec
5.拓展思考
如何正确做web应用的压力测试
1) 首先说一下如何产生压力,产生压力的方法有很多,通常可以写脚本产生压力机器人对服务器进行发包和收包操作,也可以使用现有的工具(像jmeter、LoadRunner这些),所以说产生压力其实并不难,难点在于产生的压力是不是真实地反映了实际用户的操作场景。举个例子来说,对游戏来说单纯的并发登陆场景在整个线上环境中的占比可能并不大(新开服等特殊情况除外),相反“登陆-开始战斗-结束战斗”、不同用户执行不同动作这种“混合模式”占了更大的比重。所以如何从实际环境中提炼出具体的场景比重,并且把这种比重转化成实际压力是一个重要的关注点。
(2) 产生压力之后,通常我们可以拿到TPS、响应时延等性能数据,那么如何定位性能问题呢?TPS、响应时延只能告诉你服务器是否存在问题,但不能帮助你定位问题。这些表面背后是整个后台处理逻辑综合作用的结果,这时候可以先关注系统的CPU、内存、IO、网络,对比在tps、时延达到瓶颈时这些系统数据的情况,确定性能问题是系统哪一部分造成的,然后再回到代码的逻辑中逐个优化这些点。
(3) 当服务器的整体性能就可以相对稳定下来,这时候就需要对自己服务器的承载能力有一个预估,通过产生真实压力、对比系统数据,大致可以对单套系统的处理能力有个真实的评价,然后结合业务规模配置服务器数量。可以看下腾讯wetest的这个压测工具http://wetest.qq.com/gaps/
6.参考文献
7.更多讨论
一.为什么jmeter里的报告要叫聚合报告?
普通报告是每一个请求的记录都写出来 聚合的就是算出平均值写出来
二.TPS怎么测?
用一个插件测tps http://blog.csdn.net/defonds/article/details/54576604
三.JMeter的线程发送HTTP请求时,是连续不断的发送请求,还是等上一个请求得到响应之后,再发下一个请求?
是一个一个开始测的。
四.不同的线程数下,接口的反应时间不同,如何选择合适的线程数?
响应时间在200MS之内的时候90%Line的TPS是多少。这是系统支持并发数的含义。
五.QPS和TPS的区别?
TPS 即服务器每秒处理的事务数.
QPS是每秒查询率。
六.线程有上限吗,有的话是多少,线程上限有什么决定?
看自己本地机器的性能。
七.压力测试在整个开发的哪些过程进行?
在demo之前。
八。发布线上要达到一个怎样的标准?
不能出问题,响应时间在200ms以内
感谢大家观看!
今天的分享就到这里啦,欢迎大家点赞、转发、留言、拍砖~