一直想对性能测试做个总结，但是一直拖到现在，因为最近对新接手项目进行了简单压测，所以趁着热度进行总结下。
性能测试简单来讲就是通过模拟大量用户操作来检验系统稳定性。
常用的性能测试工具有loadrunner、jmeter，因本人重点负责接口，所以使用jmeter多一些，下面总结也偏向接口多一点。
性能测试从压测场景来讲有以下分类：
1、压力测试，需要保障大并发下系统处理能力。
2、稳定性测试，需要保障长时间满负荷下系统的准确性。
性能测试从压测需求来源来讲有以下分类：
1、第三方压测，只做压测、出具报告。
2、项目内持续调优，出具阶段性压测报告，不出具具体单次压测报告，以解决压测问题为主。
性能测试从压测范围来讲有以下分类：
1、单业务场景压测，单个接口，比如充值接口。
2、混合业务场景压测，多个干系类接口，比如充值、扣减、余额查询等有逻辑关系接口。
3、联合压测，跨中心，跨系统，比如模拟用户实际下单流程，同时对商品中心、用户中心、账户中心等进行等比例qps压测。
性能测试从压测流程来讲有以下分类：
1、全流程压测，根据业务流程调整压测脚本，比如先充值、再扣减、再下单、再订单查询。
2、局部压测，类似于单接口压测。
3、团队代码内压测，只压测自己团队负责代码，比如充值接口内部调多个三方接口，则三方接口使用挡板数据，忽略三方接口耗时。
以上总结完压测场景，下面则总结下压测过程遇到问题以及常见性能问题。
压测过程常见遇到问题：
1、压力机环境搭建问题，比如压测工具在windows/linux环境下部署是否成功，是否能正常跑起来。
2、压测环境搭建问题，数据预置，应用部署，数据预置好不好，全不全，多不多直接影响压测结果。
3、压测脚本问题：
（1）脚本调用顺序问题，比如先充值、再扣减，若先扣减再充值，则会2个业务都会报错。
（2）脚本取参数问题，比如是随机取参，还是顺序取参，常见手机号需要顺序取参，则可以使用CVS文件方式。
（3）脚本协议问题，httpclint4还是java，部分get 请求下影响准确性。
（3）断言准确性问题，比如什么业务报错是正常业务，什么报错需要统计当前请求为未成功请求。
（4）windows与linux环境问题，比如CVS在linux下为相对目录，调整脚本需要记得切换CVS地址。
（5）定时器问题，有前后依赖的接口需要使用定时器来模拟真实时延。
（6）用户参数问题，哪个参数需要使用参数化，参数化规则是什么，良好的参数化有助于模拟实际压测。
4、压测数据问题：
（1）压测数据需要随机分布，比如取CVS时若手机号连续使用同一个或同一时间点使用同一个都影响压测结果，也不符合实际场景。
（2）压测数据需要覆盖全库，全表，比如分库、分表的系统，根据分库分表逻辑合理预置脚本数据均匀覆盖每一个库、每一个表。
（3）压测数据需要考虑业务逻辑，根据业务等比例分配请求比例。
5、压测执行过程问题：
（1）是否有相同脚本在执行，或者未执行完成，重复执行。
（2）多次执行压测脚本，系统是否恢复，上次压测系统压力是否释放，若没有则影响后续压测准确性，需等待系统冷却。
（3）线程数、执行时间是否可以动态配置，灵活运用。
（4）避免多次上次脚本。
（5）report及聚合报告不允许多次生成，需随时调整命令。
（6）如何多压力机同时执行多脚本，且时间差配置，需参考业务。
（7）如何配置脚本自动触发，比如jmeter脚本可以将命令放在sh中，在crontab定时触发jmeter脚本。
6、压测报告问题
（1）报告指标是否为自己需要指标。
（2）压测报告是否精准提示error报错统计。
（3）压测报告是否自动通过邮件发送到个人邮箱。
（4）多次压测如何求均值，出综合报告。
压测常见性能问题：
1、tps上不去。
（1）线程数影响tps，设置多大线程数需要结合业务设置。
（2）应用程序处理能力差，比如单pod、单线程处理。
（3）硬件差，比如数据库所在硬盘较老，IO读写慢。
（4）压力机配置低，常见于windows无法长时间、大线程量的执行。
（5）脚本逻辑问题，涉及到参数是否有乐观锁，并发锁，合理分布压测参数，减少脚本对tps影响。
2、应用程序问题。
（1）并发锁设置不合理，比如根据手机号加锁，充值和余额查询是非线性的，不能充值的时候不允许手机号办理扣减、余额查询等业务。
（2）代码逻辑问题，优先校验什么，其次校验什么，需要合理分配。
（3）sql复杂度问题，比如有没有使用索引，查的表是否合理等。
（4）应用数量、中间件使用流程等是否合理，数据是否准确，比如mq不能用于核心计算类业务，因为mq数据容易丢。
（5）内存溢出。
（6）空指针。
（7）并发问题，数据重复入库等问题。
（8）数据库主从问题，程序满负荷下主从同步时延会增加，因此内部校验哪一步查主库，哪一步查从库需要合理分配。
（9）程序控件问题，比如sharding-jdbc版本，redis版本等。
（10）程序连接数问题，数据库连接、中间件连接数大小、程序超时释放等参数配置合理性。
（11）日志级别问题，什么业务什么日志级别，全info必然影响处理能力。
（12）filebeat logstash程序采集大量日志导致kafka消费能力问题。
（13）程序参数配置不合理，内存限制、CPU限制等。
（14）业务问题，导致数据库死锁。
3、数据库问题。
（1）集群模式、主从从，自动切换，数据库指标检测等影响程序稳定性。
（2）连接数配置，超时时间配置，等参数问题。
（3）跨库联合查询性能问题。
4、硬件问题。
（1）服务器CPU配置。
（2）服务器硬盘配置。
（3）服务器集群配置。
5、网络问题。
（1）Nginx负载。
（2）kong转发。
（3）程序内部调用协议等。
以上为个人对自己接触到性能的一些总结，总之一句话，要想程序处理能力强，需要各方各面的协调配合才能保证程序。
实际运营中，系统的稳定性重要性要比系统的高处理能力重要。
另附现在负责项目TPS指标：
现网目前每天480万订单，按峰值800万订单计算。每天12小时，800万订单，80%订单量发生在20%时间内估算。
TPS=(800万0.8)/(12小时0.2)=740.74/秒
