前言:sql
因业务须要,在双11来临之际须要对多个业务核心接口作压测工做,话很少说,直接记录(如下记录为本人的切实感觉,不表明任何立场,若有出入请另行百度,本人只作比较,方便往后回顾,谢谢)数据库
我的从如下几个角度进行阐述和总结:apache
一、压测常识服务器
二、服务器性能监控范围网络
三、脚本编写与压测策略架构
四、压测实战并发
五、压测结果查看与分析负载均衡
六、异常问题定位与分析性能
七、服务器性能监控测试
八、JVM监控
九、测试报告
十、踩过的坑
负载测试:
经过逐步加压的方法,达到既定的性能阈值的目标,阈值的设定应是小于某个值,如cpu使用率小于等于80%
压力测试:
经过逐步加压的方法,使得系统的某些资源达到饱和,甚至失效的状态,简单粗暴的解释就是什么条件能把系统压崩溃
并发测试:
在同一时间內,多个虚拟用户在同时访问同一个模块,同一个功能,一般的测试方法就是设置集合点
容量测试:
一般是指数据库层面的,目标是获取数据库的最佳容量能力。又称为容量预估。具体测试方法为在必定的并发用户,不一样的技术数据量下,观察数据库的处理能力,即获取数据库的各项性能指标
可靠性测试:
又称为稳定性测试或疲劳测试。是指系统在高压状况下,长时间的运行是否稳定。
如cpu使用率在80%以上,7*24小时的运行,系统是否稳定
异常测试:
又称为失败测试。是指系统架构方面的测试,如在负载均衡中,要测试宕机,节点挂掉等状况的系统反映
事物
从客户端发起的一个请求或多个请求(这些请求组成一个完成的操做),到客户端收到服务器返回的响应
请求响应时间
客户端发起的一个请求开始,到客户端接收从服务器返回的响应,整个过程所耗费的时间
事物响应时间
事务多是一个或者多个请求组成的,事物响应时间主要针对于用户的角度而言,如转帐
并发
没有严格意义上的并发。并发总有前后,不管差距是1毫秒仍是1微秒,总有一个时间差。因此并发讲的是一个时间范围内,好比1S内,
举例:
1、多用户在系统上进行同一操做,好比双11,你们针对同一种商品进行秒杀
2、多用户在系统上进行不一样操做,好比双11,你们针对不一样商品进行秒杀,或者你们有进行其余操做,好比商品浏览
并发用户数
同一单位时间内,对系统发起请求的用户数量
吞吐量
一次性能测试过程当中网络上传输数据量的总和
一、CPU
二、磁盘
三、内存
四、网络
五、版本
六、性能损耗的计算方式(怎么计算性能损耗:相同的指标,相同的场景,相同的用户并发数进行屡次一样的压测)
一、由简单到复杂:先压单一场景,再压复杂场景
二、由优先级高到低:先压重点业务点,再压次要的
三、由单独到并行:先单独压业务点,再同时并行压业务点,由于生产场景是多个业务点在操做
PS:脚本编写,我这边全程用Jmeter3.3版本进行编写,这里我认为压测控制好合适的 线程数、持续时间、循环次数这是性能开始的核心,
若是想要测试出接口的拐点,则直接把线程数设置稍微大一点,持续时间设置短一点(我通常设置60S,线程数看接口性质,若是是dubbo接口我会设置稍微大一点,若是是普通的http接口,通常先设置100个线程数,而后逐步加压,一直压到服务器性能在一个峰值出现拐点后,大概就能够看出该接口的QPS是多少了)
PS:本人是在公司内网环境下进行压测的,那么压测服务机与压力机则会在同一网段下,否则会受带宽限制影响,那样压出来的测试结果则测不出接口性能瓶颈,
一、下载Jmeter zip包到服务器
二、解压unzip apache-jmeter-3.3.zip
三、给jmeter.sh 赋权 ,进到解压目录的 /jmeter/bin 下,chmod 777 jmeter.sh,可用 sh jmeter.sh -v 来检测命令是否可用
一、作压测时,没有配置host,后果会致使qps很低,几乎为0
二、不熟悉业务操做时,或者数据层面的转换,可找测试同窗确认操做或者找开发肯定数据(数据能永久用的,就准备好sql脚本,结果就是省时省力)
三、造数据(测试优惠券的时候,一张券只能领一次,为了1W张券能重复领取,须要改数据库优惠券状态)
四、测试报告(前期没规范,一顿瞎捣鼓)
五、压测环境相对的稳定性(不要三天段电,两天断网的,重启服务太多了,中间件等,恶心)
JVM监控-JprofilerJVM监控JVM监控-Jprofiler-Jprofiler