性能基础知识

监控：

容量测试和稳定性测试时启动nmon监控。

 

做测试前响应需加断言，保证测试正确性

 

性能测试的价值：
在性能测试分析优化之前，如果 TPS 是 100，你做完了之后 TPS 是 10000，这就是价值。

在性能测试分析优化之前，如果响应时间是 0.1ms，你做完了之后是 0.01ms，这就是有价值。

在性能测试分析优化之前，如果 CPU 使用率是 100%，你做完了之后是 50%，这就是有价值。

 

 

要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”

 

 

 

开始性能测试前需要了解的内容：

1、项目具体需求。

2、指标：响应时间在多少以内，并发数多少，tps多少，总tps多少，稳定性交易总量多少，事务成功率，交易波动范围，稳定运行时长，资源利用率，测哪些交易，哪些接口,测试哪些场景。

3、环境：生产环境服务器数量，测试环境服务器数量，按照资源配比得出测试指标。

4、协议：系统用什么协议进行通讯。

5、压力机数量：如果并发用户数太多，需要把压力发到不同的压力机，不然可能会存在压力机瓶颈问题，导致tps和响应时间抖动。

6、交易占比：分析线上日志得出tps占比。

7、系统架构：请求流经过哪些环节，压测时监控这些环节。

 

测试：

1、基准：一个用户迭代100次，关注响应时间，事务成功率100%。

2、负载：10个用户跑10分钟，关注响应时间，事务成功率100%。

3、容量：估算一个总tps，根据公式计算出每个交易的pacing和vu，获取系统最大处理能力（最优容量），再令外测出三个梯度作为对比（两组小于最优容量，一组大于最优容量），四组容量VU等差，tps等差，对比每组容量实际占比和测试占比（越接近越能模拟真实场景），关注响应时间，总tps，tps，事务成功率，AP cpu利用率，DB cpu利用率，线程死锁，数据库死锁。

       其中响应时间应小于负载测试时间，总tps应约等于预估总tps（相差不超过10是正常的），每个交易的tps应接近预估总tps*占比，事务成功率100%，AP cpu小于60%，DB cpu小于80%。dump线程栈检测是否有线程死锁，查看数据库日志看是否有数据库死锁。

4、稳定性：采取最优容量的80%作为压力持续运行24小时，观察系统长时间运行的性能表现，关注响应时间，tps，总tps，事务成功率，交易总数，观察是否有内存溢出（堆溢出，栈溢出，持久代溢出），cpu利用率是否达标，mem是否不持续增长，是否能正常触发fullgc，gc时间，gc频率， fullgc时间，fullgc频率（重点关注，JVM调优就是为了减少fullgc频率）。

 

 

性能分析流程及方法：

先从硬件开始，还是先从代码或数据库。从操作系统、网络、协议，还是从应用程序代码，数据库调优，中间件配置等方面入手。

　　中间件又有不同，虽然都是中间件，每一样拎出来往深了学都不是一朝一夕之功。但调优对于每一项的要求又不仅仅是“知道”或“会使用”这么简单。起码要达到“如何更好的使用”。

　　常看到性能测试书中说，性能测试不单单是性能测试工程师一个人的事儿。需要DBA 、开发人员、运维人员的配合完成。但是在不少情况下性能测试是由性能测试人员独立完成的，了解系统架构的的各个模块对于自身的提高也有很大帮助。

最后，如果达到了预期目标，调优工作就基本可以结束了。