电商平台的抢购活动，12306春运抢票，微信抢红包等，相信大家一定不会陌生，这些都是高并发的应用场景，那怎样去模拟这些场景来验证我们的系统抗压能力呢？
压测维度及方案
我们最先想到的例如Jmeter,loadrunner等压测工具，一上来先撸几百个线程，然后分析各种结果图，聚合报告，服务器CPU占用率, 内存，IO 等各种指标，其实并发多少个虚拟用户，不同的公司产品有不同的策略，对于产品性能的要求也应该是逐步进阶的，不同的用户量有不同的要求
首先: 对于用户量，应该统计几个维度：注册人数，在线人数，并发用户数，针对秒杀活动，一般情况
并发用户数 = 在线人数 * 0.8
更理想的并发的虚拟用户数应该是根据以往的运营数据来推测，假设系统的注册人数为5000人，活动在线人数为1250人，并发数为：1250*0.8=1000
其次：一次http的请求，从客户端发起，可能要经过负载均衡服务，网关，tomcat服务，所以并发瓶颈可能发生在其中任何一个节点，压测策略
- 压测空实现的接口（代码中无相关耗时操作和sql操作），
- 在压测其它接口，对比这两种压测结果，可能会更有利于我们分析是哪个节点对性能影响较大，从而有针对性的优化
- 分析压测结果，压测结果一般需要关注几个重要指标：吞吐量，错误率，响应时间（遵循2-5-10原则）
压测流程
基于以上分析，我们具体的压测流程如下：
压测空接口
先压测空接口，jmeter新建线程组，并发用户数设置为1000，循环1次，并增加集合点，添加查看结果树，图形结果，聚合报告, TPS查看
压测结果如下：成功100个，失败900个，接口报错返回500
重新使用110个线程压测，失败10个，接口报错返回500，可推测某个节点可能对线程数量做了限制，分析后，发现网关工程做了信号量限制,最大100，查看网关工程的application.yml文件，修改相关参数配置，例如增大至5000：
再次使用jmeter并发1000个线程，压测结果如下：吞吐量=241.1/sec ，平均响应时间<5s，错误率=0.00%，基本符合压测要求
压测业务接口
对相关业务接口，使用jmeter单次并发1000个线程，发现部分请求会报超时：
jmeter该接口的平均响应时间，为33s，考虑有可能是超过了服务器设置的超时时间，首先查看nginx超时时间,发现超时参数为30s，修改至60 s, 重新并发，问题解决，压测结果如下：
聚合报告：
Linux服务器相关指标：
压测前：
压测期间：
测试结论： 吞吐量= 27.6/sec不满足要求,90%用户响应时间=33.356s,响应时间>5s，不符合要求,压测瞬间服务器cpu占用率较高
模拟现实
因为现实情况下，压力是持续一段时间存在的，所以需要对接口进行一段时间的压测，jmeter线程组上需要勾选Scheduler,然后在Scheduler Configuration上设置Duration持续时间:
总结：
接口的压测需要根据产品，项目的要求来制定具体的压测策略，压测结果需要关注吞吐量，响应时间，错误率，资源利用率，但对系统的性能测试不仅仅是单接口的压测，还涉及的负载加压测试，稳定性测试，全链路压测等等，以适应产品的性能要求。
