性能调优-思路篇

通过jmeter进行压测，添加聚合报告，可查看到99%响应时间，还有thoughput处理请求数
1.如果响应时间小，则证明服务器处理能力强，反之，证明服务器处理能力下降
2.jmeter聚合报告99%响应时间如果小于一秒，说明服务器处理能力强，可预估当前服务器没性能问题，反之，则要对服务器逐个排查

jmeter压测策略
1.每增加一次并发线程数，需要观察5-10分钟，重点观察99%响应时间和thoughput
2.如果没问题继续增加线程数

压测报告格式（面试时也可以用到）
通过jemter聚合报告，说清楚
//您好，当前使用了几个并发线程数压测了几个接口，每个接口的99%响应时间为多少，thoughput为多少
当前使用几个并发线程数压测了几个接口分别为XXX，每个接口的tps是多少，响应时间是多少

何时引入监控
理想情况不用引入监控

只有不理想的时候才引入监控

理想情况
当增加并发线程数，thoughput也增加，响应时间比较小，预估当前无性能问题。
不理想情况包括
当我们增加并发线程数，但是在jmeter中看到的thoughput这一列的数据并没有增大还可能有降低的情况，响应时间大于一秒且越来越大，并有报错。

压力上不去的原因
1.网络带宽的原因（计算网络带宽和jmeterd聚合报告中的发送和接受字节数做对比）
2.自身硬件问题，查看cpu，磁盘等的容量
3.服务器端瓶颈（有瓶颈的话，代码托着tomcat线程不释放，jmeter迟迟得不到响应结果，压力上不去）
4.压力机和被测服务在同一网段内（排除防火墙的干预）

redis有问题
1.可能是代码有问题
2.如果不是代码问题，则是自身配置有问题
如果redis配置本身比较小，则可以增大redis配置，但不应过高，如果过高，则可能由于瞬间压力较大，把redis压挂掉

面试题
当报错率越来越大的时候，请问可能是什么原因造成的？
答：您好，请问咱们这边是什么样的一个架构呢？
我之前所做的项目都是nginx下边挂了tomcat,tomcat部署java代码应用到jvm(java虚拟机)，java代码去操作redis和数据库
基于这个架构，和您说一下可能的原因如下
1.可能是这个架构中的某个环节的服务器挂掉了，如果挂掉了，则不能够处理请求，则响应时间变大，报错率上升
2.可能是jvm内存溢出，如果jvm内存溢出，则是代码有问题，代码中的堆数据被引用不能够被gc掉，导致内存溢出
3.可能是代码有问题，如果代码有问题则jmeter发送的请求，不能够被处理，java代码线程不释放，则会造成超时报错
4.可能是代码借了redis连接池连接没归还，如果代码借了redis连接池不归还链接，则会造成超时报错
5.可能是代码借了数据库连接池连接没归还，如果代码借了数据库连接池内的连接不归还，则会造成超时报错

计算成功tps与失败tps

从jmeter得到的tps是总的tps，总的时间
总的tps/总的时间=每秒的tps   
每秒成功的tps=每秒的tps*成功率
每秒失败的tps=每秒的tps*失败率