1、第一次做压测，一定要先看别人的压测报告（可以知道压测有哪些指标，有哪些压测方案，以及明确压测的目标，还可以弥补监控和压测指标配置缺漏等问题）
2、第一次做压测，一定要全方位做好安全评估（最好做到请教或请求各个组件负责人评估和配合压测，尤其是线上压测，系统所依赖的数据库、缓存、其他组件，以及依赖的其他线上接口、资源等压垮会有什么影响，有木有补救、降级措施，混入脏数据是否能清理干净等等）。规范和安全评估: 服务端性能测试安全操作规范
3、正确的评估，默认的压测资源是否满足需求
4、默认资源最大并发用户数为2，并发数是100，QPS大约在800左右，只需要调整并发用户数和单台主机默认用户数，以及压测时长即可
5、并发用户数!=QPS，具体并发用户数，可查看下表并发数
6、17:30～19:00是网络不稳定期（18:30左右效果最明显），这时候做网络不稳定压测，非常理想
7、约定，简单压测120s即可，但是正规压测请调到600s或以上
8、压测脚本可以集成到Jenkins里，所以核心业务完全可以每次Jenkins构建都做一次简单压测
9、使用域名在连续请求量在20W～30W以后会出现轻微的失败，大约占0.01%~0.08%，所以压测，请直接使用ip+端口号
10、压测方式推荐，由小到大逐步压测，如：
压测接口
并发数
执行时间
QPS
平均响应时间
t op50响应时间
top90响应时间
top99响应时间
成功率
xxController.getXX
10
600s
2284
4ms
4ms
5ms
7ms
100%
xxController.getXX15
600s
2883
5ms
4ms
7ms
12ms
100%
xxController.getXX20
600s
3292
6ms
5ms
8ms
17ms
100%
xxController.getXX25
600s
3500
7ms
6ms
10ms
20ms
100%
xxController.getXX30
600s
3519
8ms
7ms
11ms
23ms
100%
xxController.getXX35
600s
3616
9ms
8ms
13ms
27ms
100%
xxController.getXX40
600s
3594
11ms
10ms
15ms
34ms
100%
xxController.getXX45
600s
3644
12ms
11ms
17ms
36ms
100%
xxController.getXX50
600s
3655
13ms
12ms
19ms
37ms
100%
1、评估压测的目标、范围和作用（不清楚可先查看别人的测试报告）
2、安全评估（线上压测，尤其是需要申请资源，切勿只看wiki或摸索操作）。规范和安全评估: 服务端性能测试安全操作规范
3、提前配置好压测的事务，场景，测试数据（最好将预期结果也配置好）
4、默认分配的的压测资源是否已经满足压测（默认资源最大并发用户数为2，并发数是100，QPS大约在800左右）
5、开始压测（压测完毕最好形成压测报告的wiki）
1、若默认分配的的压测资源不满足压测需求可先联系QA，商榷资源需求、安全评估、以及压测时间段，并形成wiki和发送资源申请邮件
2、提前准备好压测报告的wiki，方便压测完毕即可发送压测邮件（也能明确压测内容）
3、创建群，把发送邮件的相关人员拉入群，等待压测负责人分配资源
4、分配完毕后即可在默认资源配置下修改配置来开工压测
5、压测完毕后，形成压测报告wiki和邮件（尽量当天完成压测和压测报告）
2个集群n61n62共200台机器。高峰QPS 5800，压测一般4倍。搜索一般qps1w多，200多万请求，压测时常10分钟，双十一30分钟。关注指标CPU tp90 tp99 平均时长 qps。压测脚本：文件分批处理，多线程。10万条，谷歌的guava
代码发布自动触发自动化case
