性能测试学习

lumix命令
top -查询cpu使用率的进程号（然后按c 显示进程对应域信息）
执行shift +H 查询到对应的线程号
用jstack +线程号 检查日志（由于jstack日志使用的是十六进制的线程号，且只能是小写字母）
查看内存： free -m ：空闲情况，以兆为单位
jstat -gcutil 192414 1s --查询jvm内存
S0：幸存1区当前使用比例
S1：幸存2区当前使用比例
E：伊甸园区使用比例
O：老年代使用比例
M：元数据区使用比例
CCS：压缩使用比例
YGC：年轻代垃圾回收次数
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

简单总结
出现任何问题，首先检查各种监控数据

业务指标
Avg Resp：平均响应时间
99% Line：响应时间的99%分位数，即99%的请求响应时间小于此值
Error%：错误率
TPS：每秒完成的请求数，很多人也叫QPS
服务器指标
CPU Load：特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数。反应进程等待CPU的情况，略低于CPU核数为正常
CPU User Util：用户进程CPU使用率
CPU System Util: 系统进程CPU使用率
CPU Idle Util：空闲CPU比例，可认为100-Idle为实际CPU使用率
Used Memory：已使用的内存大小（包含cached/buffers）

JVM指标
已提交堆大小：当前堆大小（不包含已回收的）
Full GC总次数： 监控期内Full GC（老生代GC）总次数
Full GC平均时间：监控期内Full GC的平均时间
Full GC越少越好，时间越短越好

Current QPS：每秒完成的查询请求数（select）
TPS：每秒完成的事务数（insert，update，delete）
慢查询：执行超过300ms的sql请求个数（具体阈值由参数long_query_time定义）
表缓存命中率：open_tables/opened_tables
当前连接数： Threads_connected，与show processlist相同
当前并发数：Threads_running，真正在执行的sql数量

压力机指标
理想状态下（压力机无性能损耗）TPS的公式：TPS=线程数/响应延时
当实际TPS与计算结果偏差较大时，需要关注压力机性能

jmeter的性能测试建议：
Do not use GUI mode
不使用GUI模式
Use Remote and Distributed testing for larger load testing
使用远程和分布式测试进行更大的负载测试
Do not add Listeners to your Jmeter test plan
不要在Jmeter测试计划中添加监听器
Do not add Graphs to your Jmeter test plan
不要在Jmeter测试计划中添加图表
Add relevant Assertions and Post-processors elements only
仅添加相关断言和后处理器元素
Do not use XPATH extractor
不使用XPATH提取器
Use JSR 223 and Groovy for scripting
使用JSR 223和Groovy编写脚本
Generate reports after run
运行后生成报告

常见的CPU高的问题：
1、加解密/编解码 encodetostring
2、序列化/反序列化 java.io.ObjectOutputStream代表对象输出流，它的writeObject(Object obj)方法可对参数指定的obj对象进行序列化，把得到的字节序列写到一个目标输出流中。
3、java.io.ObjectInputStream代表对象输入流，它的readObject()方法从一个源输入流中读取字节序列，再把它们反序列化为一个对象，并将其返回。
死循环
4、非线程安全 定义在类中的静态成员变量，一定要小心写操作的线程安全问题
解决方法：
加synchronized关键字（可能影响性能）
放在方法中定义局部变量（会创建多个实例，有可能增加内存开销和CPU使用率）
5、连接数少
数据库，redis，http请求等都会涉及到连接数的配置，连接数过少会显著影响性能
通过观察jstack结果，如果有大量线程停在类似getConnection或leaseConnection方法上，证明连接数已成为瓶颈

java回收机制总结
一：新生代：主要是用来存放新生的对象。一般占据堆的1/3空间。由于频繁创建对象，所以新生代会频繁触发MinorGC进行垃圾回收。
新生代又分为 Eden区、ServivorFrom、ServivorTo三个区
Eden区：Java新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老年代）。当Eden区内存不够的时候就会触发MinorGC，对新生代区进行一次垃圾回收。
ServivorTo：保留了一次MinorGC过程中的幸存者。
ServivorFrom：上一次GC的幸存者，作为这一次GC的被扫描者。
MinorGC的过程：MinorGC采用复制算法。首先，把Eden和ServivorFrom区域中存活的对象复制到ServicorTo区域（如果有对象的年龄以及达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1（如果ServicorTo不够位置了就放到老年区）；然后，清空Eden和ServicorFrom中的对象；最后，ServicorTo和ServicorFrom互换，原ServicorTo成为下一次GC时的ServicorFrom区。
二：老年代：主要存放应用程序中生命周期长的内存对象。
老年代的对象比较稳定，所以MajorGC不会频繁执行。在进行MajorGC前一般都先进行了一次MinorGC，使得有新生代的对象晋身入老年代，导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次MajorGC进行垃圾回收腾出空间。
MajorGC采用标记—清除算法：首先扫描一次所有老年代，标记出存活的对象，然后回收没有标记的对象。MajorGC的耗时比较长，因为要扫描再回收。MajorGC会产生内存碎片，为了减少内存损耗，我们一般需要进行合并或者标记出来方便下次直接分配。
当老年代也满了装不下的时候，就会抛出OOM（Out of Memory）异常。

压测注意点：
1、接口压测还要测一下健壮性,就是把依赖接口延时设置到极限和超时,看看大量时会不会出问题,这个各压5分钟就好了
2、还有必须要分析CPU火焰图http://gitlab.tools.vipshop.com/venus-framework/vjtools/tree/master/handbook/async-profiler
3、跟大家分享一下单机压测场景,压测的时候不要慢慢上压力,让它瞬间打满,没有预热的情况下2分钟后要达到正常服务,且2分钟内不能有full gc