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