性能测试（压测500）同一个用户
1.填写接口
2.设置虚拟用户数，时间
3.添加插件
监听器中的插件
@gc - Active Threads Over Timeip 活动线程时间
@gc - AutoStop Listener 自动停止侦听器
@gc - Bytes Throughput Over Timejp 字节吞吐量随时间变化
@gc -Composite Graph 综合图
@gc - Connect Times Over Timejp 连接时间
@gc -Console Status Loggerjp 控制台状态记录器
@gc - DbMon Samples Collectorjp （DbMon Collectorjp样品收集器
@gc -Flexible File Writer 监听器之灵活的文件写入
@gc - Graphs Generatorjip 图形发生器
@gc - Hits per Second 每秒点击次数
@gc -JMXMon Samples Collectorjp （JMXMon样品收集器
@gc - Page Data Extractor 页面数据提取器
@gc - PerfMon Metrics Collectorjip 性能指标收集器
@gc - Response Codes per Secondjip 每秒响应数
@gc - Response Latencies Over Timejip 随时间间隔变化的响应延迟
@gc - Response Times Distributionjip 响应时间分布图
@gc - Response Times Over Time 随时间变化的响应时间
@gc - Response Times Percentilesjip 响应时间百分位数
@gc - Response Times vs Threadsjp 响应时间vs线程
@gc - Synthesis Report (filtered) 综合报告（过滤）
@gc - Transaction Throughput vs Threadsjip 整个线程的事务
@gc - Transactions per Second 每秒事务数
查看插件插收集的数据
1.聚合报告
2.综合报告
3.jp@gc - 每秒事务数
简写：TPS( Transactions per Second)
定义：TPS：每秒事务数，性能测试中，最重要的2个指标之一
该插件的作用是在测试脚本执行过程中，监控查看服务器的TPS表现如整体趋势、实时平均值走向、稳定性等。
横坐标是运行时间，纵坐标是tps值
红色表示通过的tps，绿色表示失败的
4.hps
简写：HPS(Hits per Second)
动态监听单位时间的点击率，也就是触发的请求数。其中横坐标是运行时间，纵坐标是HPS值。
点击率波动较大，且不能持续上升。说明性能很不稳
5.jp@gc - 每秒响应数
@gc - Response Codes per Second 每秒响应数
表明jmeter测试期间，随着时间的推移返回的响应码，从中我们可以看到测试期间在哪个时间段内出现了错误，就可以分析在该时间内系统的什么环境因素导致的错误。
code，是指请求的status，如200,404,504,502等。
6.综合图
1）组合式的监听器。
横坐标是运行时间，
纵坐标是各性能数据的汇总值（其中有一些数据需要除10）。
2）
在它的Graphs里面能够设置多少个图表一块儿展现，它能够同时展现多个图表线程这里能够将一些图表结合在一块儿查看性能趋势和走向，有利于对比和结合查看性能
7.活动线程时间
Active Threads Over Time：每秒的活动线程数，X轴表示访问的时刻，Y轴表示活动线程数，F（X,Y）表示某个时刻的活动线程数。监听单位时间内活动的线程数。
横坐标是单位时间（单位是毫秒），
纵坐标是活动线程数（也就是并发数）
F（X,Y）表示某个时刻的活动线程数。
8.AutoStop Listener 自动监听器
定义：设置当发生某些预期以外的状况时自动中止测试测
（1）average Response Time is greater than 10000ms for 10 seconds ：10s平均响应时间大于10000ms就中止测
（2）average Latency is greater than 5000ms for 10 seconds ：链接10s平均等待时间大于5000ms就中止测试
（3）Error Rate is greater than 50% for 10 seconds ：10s内错误率一直高于50％就中止测试、
9.Bytes Throughput Over Time 不一样时间吞吐量
@gc - Bytes Throughput Over Time:不一样时间吞吐量（字节Bytes）展现（图表） 聚合报告里，Throughput是按请求个数来展现的，
好比说1.9/sec，就是每s发送1.9个请求；而这里的展现是按字节Bytes来展现的图表，表示每秒发送多少字节插件
10.Connect Times Over Time连接时间
Connect Time Over Time（连接时间变化曲线图），随着时间变化，每个时间节点花费在连接上的平均时间 脚本运行期间，事务（请求）建立连接所花费的平均时间变化趋势图
包括 SSL 三次握手的时间
当出现链 Connection Time Out 的错误时，Connect Time 就会等于链接超时时间
11.控制台状态记录器
12.样品收集器
13.@gc -Flexible File Writer 监听器之灵活的文件写入
Filename：结果记录的文件，将结果保存的文件
Overwirte existing file：是否覆盖这个文件，若是该文件有内容，勾选决定每次的结果是否覆盖文件的内容
Ｗrite File Header：文件的头(即文件的第一行)
Record each sample：记录不一样的sample，sample如http请求的sample（记录哪些内容，什么顺序，如何隔开不一样的值）
Write File Footer：文件的结尾（即文件的最后一行）
14.图形发生器
15.@gc -JMXMon Samples Collector（JMXMon样品收集器）
16.页面数据提取器
17.@gc - Response Latencies Over Time 随时间间隔变化的响应延迟
定义：记录客户端发送请求完成后，服务器端返回请求以前这段时间
表明jmeter测试期间，随着时间的推移，系统的响应等待时间的变化，也是系统随着时间推移系统效率的变化。
18.gc - Response Times Distributionjip 响应时间分布图
19.Response Times Percentilesjip 响应时间百分位数'
20.@gc - Response Times vs Threads响应时间vs线程
21.@gc - Transaction Throughput vs Threads
整个线程的事务
每活动线程数可能的事务吞吐量，途中 X 轴表示的是活动线程数，Y 轴表示的是事务吞 吐量，F(X,Y)的含义是当系统处于某个活动线程数时，系统当时的事务 吞吐量是多少。
比如当有 10 个活动线程时，事务吞吐量是 100/s，而当有 20 个活动线程时，事务吞吐量 是 50/s，说明随着用户访问的增加，系统的处理 效率开始下降了。
22.表格报告
样本数目：表示当前查看时，总共发送到服务器的请求数。
最新样本：代表时间的数字，是服务器响应最后一个请求的时间。
平均：表示发送至服务端的，请求总数/总运行时间
偏离：表示服务器响应时间变化、离散程度测量值的大小。
吞吐量：服务器每分钟处理的请求数。
中间值：有一半的服务器响应时间低于改值而另一半高于该值。
图表左上角显示的值是响应时间第90百分位数的最大值。
23.表格报告
参数详细解释：
Sample#：每个请求的序号。
Start Time：每个请求开始时间。（时：分：秒.毫秒）
Thread Name：每个线程的名称（线程序号-第N次循环次数）。
Label：每个请求的自定义名称（无修改时默认显示请求类型，如Http，FTP等请求）。
Sample Time(ms)：每个请求的响应时间。（单位：毫秒）
Status：请求状态，如果为勾则表示成功，如果为叉表示失败。
Bytes：响应的字节数，请求的字节数。
Sent Bytes：发送的字节数。
Latency：延迟的时间，等待时长。（单位：毫秒）
Connect Time(ms)：连接服务器的时间。（单位：毫秒）
样本数目：所有请求个数，样本数目 = 线程数（请求用户数）* 请求次数 。（单位：个）
平均：所有请求的平均响应时间。（单位：毫秒）
最新样本：最新样本响应时间，表示服务器响应最后一个请求的时间。（单位：毫秒）
偏离：服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。
性能指标
一、性能测试指标
性能测试是通过测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。
目的：验证软件系统是否能够达到用户提出的性能指标，发现系统中存在的性能瓶颈并加以优化。
二、性能指标分为两大类：
软件指标：
术语 释义
（1）TPS: （每秒事务数）
在每秒时间内系统可处理完毕的事务数。TPS很大程度体现系统性能能力。
TPS（Transaction Per Second）是指单位时间（每秒）系统处理的事务量。事务可以是用户自定义的一系列操作或者动作的集合，比如"用户注册"事务是点击注册按钮，填写用户注册信息，点击提交按钮，以及加载注册成功页面的动作集合。
这3个个公式都是对的
第1个公式计算的是绝对的TPS，也是瞬间TPS，jmeter中的throughput是吞吐量是平均TPS，这个绝对TPS指的是某个点的值
第2个公式计算的是业务的TPS，指的是每天80%的业务量都是发生在20%的时间内，列如当前线上APP1.0试⽤系统主要为查询类交易，交易占⽐40%，系统⽣产交易量统计为1个⽉约20W笔，假设APP2.0系统上线后业务量激增到每⽇查询类20W，则每⽇总交易量T达到:
T = 20W/40%=500000笔/⽇
系统处理能⼒TPS推导:APP2.0上线后交易量最⼤500000笔/⽇,系统晚间⼏乎⽆交易量，按2:8原则推算,则(500000*80%)/(8*20%*3600)=69.4笔/秒，取整为70笔/秒，每年按业务量增长50%计算，则⼀年后系统处理能⼒指标约等于
70+70*50%=105笔/秒。
第3个公式计算和第2个有点类似，但是加了一个冗余系数这个是为了后续业务增长做容量规划使用的，比如现在的系统需要支持105笔/秒，后续随着业务增加可以扩个2-5倍。
（2）QPS(Query Per Second)
是指单位时间内查询或访问服务器的次数。
TPS和QPS的区别：
TPS和QPS的区别在于一个事务（Transaction）可以包含多次查询或访问服务器，也可以只查询或访问一次服务器。当多次查询或访问时，一个TPS相当于多个QPS；当只查询或访问一次时，一个TPS则等价于一个QPS。
（3）错误率：
经系统处理的事务出现错误的概率，对应着实际用户使用系统功能失败的情况。理想情况下，错误率应该保持极低水平。公式：错误接口数/接口数=错误率
（4）响应时间
（一）响应时间：
对请求做出响应所需要的时间。
响应时间：响应时间=网络响应时间+应用程序响应时间=（N1+N2+N3+N4）+(A1+A2+A3)
（二）国内外标准
标准可参考国外的3/5/10的原则：
（1）在3秒钟内，页面给予用户响应并有所显示，可认为是"很不错的"。
（2）在3-5秒钟内，页面给予用户响应并有所显示，可认为是"好的"。
（3）在5-10秒钟内，页面给予用户响应并有所显示，可认为是"勉强接受的"。
（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等下去。
国内标准则是：
2秒很好，5秒可以接受，8秒垃圾
平均响应时间：所有请求平均花费的时间如果有100个请求，其中98个耗时为1ms，其它两个位100ms：(98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms并不能反映服务器的整体效率，因为98个请求耗时才1ms，引申出百分位数
（三）百分位数：
以响应时间为例，指的是 98% 的请求响应时间，都处在这个值以下，更能体现整体效率
（5）并发
并发是指多个用户在同一时期内进行相同的事务处理或操作。由于用户在进行一系列操作流程时有一定的时间间隔（即用户思考时间）或者服务器处理请求有先后顺序，于是，就产生了绝对并发和相对并发概念的区分。
绝对并发是指同一时刻（即同一时间点）并发用户对服务器同时发送请求。
相对并发是指一段时间内（即同一时间区间）并发用户对服务器发送请求
并发数 :测试时同时系统发出事务请求的数量，并发线程数用以模拟同时与系统建立连接的用户。
并发用户数: 同时向系统发出事务请求的数量
并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的 操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行"严格意义上的并发"。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
并发主要是针对服务器而言，在同一时刻与服务器进行交互（指向服务器发出请求）的在线用户数。
在线用户：指某段时间内，用户访问系统的用户数，如多个用户在浏览网页，但没有对同时对服务器进行数据请求，需要与并发用户数区分开。
（6）在线用户：
指某段时间内，用户访问系统的用户数，如多个用户在浏览网页，但没有对同时对服务器进行数据请求，需要与并发用户数区分开。
（7）最佳并发用户数：
最佳并发用户数：当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待
（8） 最大并发用户数：
最大并发用户数：系统的负载一直持续，有些用户在处理而有的用户在自己最大的等待时间内等待的时候
案例：
理发店模式，简单地阐述一下，一个理发店有3个理发师，当同时来理发店的客户有3个的时候，那么理发师的资源能够有效地利用，这时3个用户数即为最佳的并发用户数；当理发店来了9个客户的时候，3个客户理发，而6个用户在等待，3个客户的等待时间为1个小时，另外的3个客户的等待时间为2小时，客户的最大忍受时间为3小时包括理发的1个小时，所以6个客户的等待时间都在客户的可以承受范围内，故9个客户是该理发店的最大并发用户数
（9）系统的平均负载：
在特定的时间内，系统正在处理的用户数和等待处理的用户数的总和
（10）峰值：
指的是系统的最大能承受的用户数的极值
只有最大并发用户数的大于系统所能承受的峰值负载，才不会造成等待空间资源的浪费，导致系统的效率低下
事务：可以看作是一个动作或是一系列动作的集合，例如登录，从登录开始到登录结束为一个事务。
（11）HPS（Hits per Second）：
一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和
（12）吞吐量 ：
单位时间内处理的客户端请求数量
（13）吞吐率：
单位时间（可以是秒/分/时/天）内网络成功传输的数据量，如请求数/秒、页面数/秒
吞吐量/传输时间,就是吞吐率.
吞入率 ：单位时间内从服务器返回的字节数，也可以单位时间内客户提交的请求数
吞吐率：
①业务角度：
单位时间（每秒）的请求数或页面数，即请求数/秒或页面数/秒；
②网络角度：
单位时间（每秒）网络中传输的数据包大小，即字节数/秒等；
③系统角度：
单位时间内服务器所承受的压力，即系统的负载能力。
（14）点击率：
单位时间每秒钟向web服务器提交的HTTP请求数
每秒钟用户向WEB服务器提 交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.
案例：
比如公众号的一篇文章被浏览了10w次，文章中的广告链接被点击了2000次，那么这条广告的点击率是2%（2000/100000*100%）
（15）点击数：
指Web Server收到的HTTP请求数
（16）点击量：
向web服务器提交的HTTP请求数
（17）PV和UV
是衡量web网站性能容量的两个重要度量指标，经常用在电子商务网站领域中用来衡量网站的活跃度。
（1）PV（Page View）
是页面的浏览量或点击量，用户对系统或者网站任何页面的每一次点击或者访问都会被记录一次浏览量或点击量，对相同页面进行多次访问浏览量或点击量也会进行累计。
（2）UV（Unique Vistor）
是系统或者网站的独立访客，一段时间内相同客户端（或PC）访问系统或者网站只会被记录一次，连续重复访问或者浏览多个系统页面次数不会进行累计。
PV和UV按照统计周期划分，可以划分为全天PV、每小时PV、全天UV和每小时UV等。在一些数据或交易量非常庞大的场景中，比如双11或618等全民购物活动时，常常还会统计峰值PV和峰值UV
三.硬件指标
cpu、 磁盘 .网络、内存，硬盘
（1）cpu
（2）内存 Memory
内存：与cpu沟通的桥梁，计算机中所有程序的运行都在内存中进行，内存分为物理内存、页面交换（Paging），SWAP内存（虚拟内存）
（3）磁盘I/O（Disk I/O），
磁盘吞吐量，指单位时间内通过磁盘的数据量。主要关注磁盘的繁忙率，如果高于70%，则磁盘瓶颈
（3）网络I/O（Network I/O）
网络吞吐量，指单位时间内通过网络的数据量，当吞吐量大于网路设备或链路最大传输能力，即带宽时，则应该考虑升级网络设备或者增加带宽，Linux命令netstate
查看硬件指标的命令
命令1: # cat /proc/cpuinfo //获取CPU详情
命令2: # top //包含CPU、内存使用等情况，常用命令
命令1： # free --h 内存
命令1：#uptime负载
命令3：#w
磁盘
命令1: #fdisk --l //查看硬盘及分区情况
命令2：# df --h //查看文件系统的磁盘空间使用情况
整体
命令：# vmstat 3 2 //每3秒一次，共2次
性能测试问题
案例1：
某次压力测试，同样并发TPS，但前期性能良好，后期数据库CPU飙升？
压测会产生大量的数据，数据增长会带来性能的损耗；压测数据不合理，导致同一设备关联多个用户，服务端不做限制；查询不合理分页，未做页数limit，导致数据库新增数据全部查询。
案例2：
响应时间过长是由什么导致的？
-
服务器硬件资源CPU、内存、磁盘达到瓶颈，可以使用监控命令排查。
-
网络问题导致，例如丢包、带宽不够等问题。
-
线程出现死锁、阻塞等问题，可以使用Jstack进行排查。
-
中间件比如mq消息队列拥堵排队等。
-
数据库层面sql不够优化，没有索引，联合索引失效等，数据库连接数不够。
案例3：
压力测试中TPS一直上不去？
这个原因比较多，压测整个链路上任何一个环节有瓶颈或者问题都有可能导致。
首先是压力机压力不够，比如用我们笔记本基本压不到那么高的TPS，所以我们公司有自己的压测平台，分布式集群压测。
-
网络带宽，单位时间内网络传输数据量过大，超过带宽处理能力，
-
数据库连接数太少，最大连接数不够。
-
CPU，内存，磁盘硬件资源达到瓶颈。
-
中间件redis也有可能存在瓶颈，比如缓存穿透，缓存过期等。
-
存在大量线程阻塞，现成死锁等。
-
中间件消息队列拥堵。
案例4：
后台指令发送满负荷工作时，数据库CPU高？
原因：后台指令发送现成每次对全量查询结果排序，结果集很大，然后取一条记录；索引区分度不高，满负荷执行时，查询频率很高；压测显示，并行发送指令的后台线程越多，数据库CPU越高，效率越低。
解决方法：
去掉ORDER BY ，增加索引后，效果不明显。因为结果集大和查询频繁两个问题没有解决，因此考虑使用设计新的方案。
新方案：设计质量发送线程池，生产者线程每台任务服务器只有一个线程，负责查询待发送指令，每次查询50条指令。每条指令包装秤一个runnable对象，放进ThreadPoolExecutor线程池，线程池大小参数设置为100或200.每当线程池满时，生产者停止生产指令，休息15秒后继续。消费之现成即线程池里的县城，参数设置为4,8或12（和不同指令类型的指令数据量成正比---）。
改进后的方案，数据库CPU降到10%以下，发送效率单机提升6倍，前可线性拓展任务服务器。
案例5：
内存溢出（堆溢出、栈溢出、持久代溢出）
解决思路：
1、调整堆内存参数，一般是增加堆内存
2、减少批处理数据量
案例6：
线程死锁：容量（压力）测试压测一段时间后，报连接超时
解决思路：
1、造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时 错误
2、找到死锁的线程，分析对应的代码
案例7：
压测TPS曲线剧烈下降或抖动
问题现象：50并发压测，TPS曲线正常应该是平缓的，波动不大，如果突然出现剧烈下降，并且短时间内无法恢复，则可能存在问题。
问题原因：一般是由于前置或bp的jvm进行垃圾回收，或者日志记录磁盘满导致的。
解决方法：如果不是特别剧烈的波动或者TPS曲线下降后长时间不反弹，则可以忽略该问题。否则，需要分析曲线下降的时刻，系统当时正在发生的事情。可以通过top命令监控当时CPU占用比价高的线程，也可以kill -3 pid杀javacore来查看线程堆栈。
案例8：
CPU高
问题现象：50并发压测，监控工具显示bp、前置CPU占用90%以上。
问题原因：业务处理中存在大量CPU计算操作。
解决方法：采用更高效的算法、数据结构替换原来消耗CPU的代码，或者采用新的设计绕过瓶颈代码，比如查找数据的逻辑，可以把List改为Map，以空间换时间；比如用Json报文替换XML报文，提高传输、解析和打印日志的效率。
导致Cpu计算资源高消耗的代码：报文格式转换、加解密、正则表达式、低效的循环、低效的正则表达式。
排查方法：
压测进行时，使用jvisualvm工具远程连接应用，点抽样器àCPU，点快照生成线程快照。采样一段时间后，抽样器会显示各个方法占用cpu时间，可以针对CPU时间占用高的方法进行优化。
使用tprofiler，jprofiler，OracleDeveloperStudio12.6-linux-x86工具分别分析消耗CPU时间长的方法，以上工具分析结果可能有些差别。针对CPU计算耗时最长的方法进行优化。
案例9：
内存泄漏
问题现象：JVM内存耗尽，后台日志抛出OutOfMemeryError异常 ；
问题原因：内存溢出问题可能的原因比较多，可能是全局的List、Map等对象不断被扩大，也可能是程序不慎将大量数据读到内存里；可能是循环操作导致，也可能后台线程定时触发加载数据导致。
解决方法：对于ibmjdk纯java应用，在jvm启动时设置-XX:+HeapDumpOnOutOfMemory Error参数，会在内存溢出时生成heapdump文件。使用ha456.jar工具打开heapdump文件，分析大对象是如何产生的。
当然，在heapdump中对象类型可能只是List这种结构，看不出具体哪个业务代码创建的对象。此时要分析所有的全局对象，列出可疑的List或Map对象，排查其溢出原因。
全局对象、引用的初始化、修改要慎重。建议应用梳理所有可能存放全局对象的代码，统一管控
案例10：
打开了太多文件
问题现象：采用合理的并发数压测，交易失败，或后台日志报错：To many open files。
问题原因：
读取配置文件或者业务数据文件后，未关闭文件流；
/etc/security/limits.conf中***打开文件数配置过小。
解决方法：
使用lsof --p pid 命令查看进程打开的文件，如果大部分文件都是同一类型的文件，说明可能未关闭文件流。找到打开文件的代码，关闭文件流即可。
如果不存在未关闭文件流的问题，且业务本身就需要处理大量文件，则修改/etc/security/limits.conf文件如下内容：
* hard nproc 10240
* soft nproc 10240
案例11：
线程阻塞在日志记录上
问题现象：系统响应时间长、通过javacore查看很多线程阻塞在打印日志上。
问题原因：log4j1.x版本较低，性能较差；大报文日志多次输出。
解决方法：
减少无效日志、删除无用日志，减少大日志输出。
升级log4j组件到log4j2，参考log4j2官方文档，配置合理的日志缓冲区，采用高效的Appenders，比如RollingRandomAccessFile。但log4j2仍然采用同步日志，不采用异步日志。因为网银系统日志量较大，异步日志队列很快就满了，如果单条日志存在大报文，还有可能导致内存溢出，因此不适合采用异步日志。如果日志量少（压测产生日志的速度，低于日志写入文件的速度），则可以使用异步日志，大幅提高性能。如果日志量较大，则不建议使用异步日志。
排查方法：
JVM启动参数中增加-XX:+HeapDumpOnCtrlBreak，压测进行时，kill -3 pid 杀几个javacore，使用jca457.jar工具打开并分析。推荐使用该工具，因为该工具可以对所有线程状态进行统计，并生成饼状图，方便查看。
压测进行时，使用jvisualvm获取jvm快照，分析线程堆栈。
案例12：
多线程并发问题
问题现象：采用合理的并发数压测，系统出现逻辑错误、交易失败或异常报错。经查是由于对象中变量被异常修改导致。
问题原因：系统中全局对象中的类变量或全局对象，被多个线程修改。
解决方法：排查系统中所有持有全局对象或类变量的代码，检查其全局变量是否可能被多个线程并行修改。
修改方法：
将全局变量转成方法内的局部变量；
对全局变量进行同步控制比如syncronized代码块，或者java.util.concurrent锁
排查方法：并发问题很可能是由全局变量或者对象导致，准确识别全局变量，通过阅读代码找问题。建议应用梳理所有可能存放全局对象的代码，统一管控，或者把所有全局对象放到一个类中，方便管理
案例13：
JMeter Address 占用的问题（jmeter地址占用问题）
搜索之后发现需要在regedit中添加注册表项MaxUserPort，TcpTimedWaitDelay重启一下就可以解决了。
解决方法：
打开注册表：ctrl+r 输入regedit
进入注册表，路径为：\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
新建DWORD值，（十进制）设置为30秒。名称:TcpTimedWaitDe,值:30
新建DWORD值，（十进制）最大连接数65534。名称:MaxUserPort,值:65534
修改完成后重启生效
面试题
1、性能问题的六个特征：
（1）、持续缓慢：
（2）、随着时间推进越来越慢、
（3）、随着负载增加越来越慢、
（4）、零星挂起或异常错误、
（5）、可预见的锁定、
（6）、突然混乱、
2、性能瓶颈
性能瓶颈定义：导致系统TPS低、响应时间长、资源（CPU、内存、网络）占用高等问题的
（1）找到性能瓶颈
瓶颈的类型：
a、网络瓶颈，如带宽，流量等形成的网络环境
b、应用服务瓶颈，如中间件的基本配置，CACHE等
c、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
d、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
e、应用程序本身瓶颈，
关键程序模块。提升该程序模块的性能，可以大幅度改善性能。
常见的性能瓶颈原因包括：数据库慢查询SQL、日志打印、xml大报文解析和格式转换、复杂业务逻辑、锁竞争等。
（2）如何找到性能瓶颈
使用jmeter或LoadRunner给每个接口的增加事务，记录其响应时间和TPS，最慢的那个接口往往是瓶颈；
分析慢交易的日志，查看是哪个操作耗时最长；
分析数据库快照，看是否有执行较慢或者全表扫描的SQL；
通过Javacore查看线程正在执行的代码，是大部分阻塞在IO上，还是大部分在进行计算。针对不同的问题，使用不同的分析工具。详细内容可以看下一章节。
（3）针对性能瓶颈进行合理优化
性能优化原则：
先优化瓶颈问题；
方案简单，尽量不引入更多复杂性，尽量不降低业务体验；
满足系统性能要求即可，不引入新的bug。
3、如何定位性能问题？
A. 查看系统日志
日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。
比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。
B. 利用性能监控工具
比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。
利用Spotlight可以监控数据库使用情况。
我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等
C.设计合理的性能测试场景
工具和日志只是手段，除此之外，还需要设计合理的性能测试场景
具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等
好的测试场景，能更加快速的发现瓶颈，定位瓶颈
D. 了解系统参数配置，可以进行后期的性能调优
4、简要说明性能测试流程？
（1） 分析性能需求。 选择用户最常用的场景进行测试，例如登录、搜索和订购。 确定绩效指标。 例如，事务通过率为100%，TOP99%为5秒，最多同时用户1000人，CPU和内存使用率低于70%。
（2）制定性能测试计划，明确测试时间(一般在功能稳定后，如第一次测试后进行)、测试环境和测试工具
（3）编写新能测试用例
（4）建立性能测试环境，准备性能测试数据
（5） 编写性能测试脚本
（6）性能测试脚本优化。 设置检查点、参数化、关联、聚合点、事务，调整思考时间，删除冗长的脚本
（7）设计测试场景，运行测试脚本，监控服务器，
（8）分析测试结果，收集并开发相关日志提单
（9）回归性能测试
（10）写测试报告
（11）性能调优
5、如何确定系统的最大负载？
通过负载测试，增加用户数量。 随着用户数量的增加，各项性能指标也相应变化。 当性能拐点出现时，例如，当用户达到某个订单时，如果响应时间突然增加，则该拐点的对应用户数可以是该系统可以装载的最大用户数。
6、你的系统哪里(哪些功能)进行了性能测试？
我们选择了用户最常用的功能进行了测试，包括登录、搜索和提交订单
7、你们的同时用户数是怎么确定的？
1 )上线一段时间，根据收集到的用户访问数据进行估计
2 )根据需求决定(高峰时间段、注册用户数、1次响应时间等
8、你们的性能测试在什么环境下进行？
独立的性能测试环境进行测试
9、你们的性能测试什么时候进行？
基准测试：功能测试后，在系统稳定时进行。
负载测试：夜深，系统无人使用时
10、如何分析性能测试结果？
首先看事物的通过率，然后分析其他性能指标。 例如，如果测试结果不可靠，如响应时间、事务通过率、CPU等指标是否满足需求，请分析并纠正异常原因，然后重新测试
11、如何识别系统瓶颈？
通过TPS指标分析，TPS是在系统单位时间内处理的事务数量。 观察当前随着用户数量的增加，系统每秒能处理的事务数是否也会增加
12、如何判断系统性能是变好了还是变坏了？
通过基准比较性能指标。
13、你们的性能测试需求来自哪里？
(1) :客户提供需求(主要)
(2 )运维需求
(3 )开发提供需求
14.具有验证码功能。 你怎么做性能测试？
1 )临时屏蔽验证码，完成性能测试后恢复
2 )使用万能的验证码
15.如何加强性能脚本？
如何加强脚本？
1 )参数化
2 )相关
3 )添加事务
4 )添加断言
5 )增加集合点
6 )增加思考时间
讲解稿
案例1
性能测试压测50怎么做的？
在工作中我测试会对单个接口进行压测或一个性能场景进行压测；首先会分析需求，根据需求分析接口和场景做性能；设计性能场景；根据性能场景使用badboy（或反向代理录制脚本）录制脚本；将录制的脚本进行参数化、并且调通；在测试计划中设置压测用户数，设置压测时间，在添加查看结果树、聚合报告、tps插件、hps插件、混合图标、图像报告、表单报告等插件，在服务器中也可以使用nmon来采集硬件指标：cpu、内存、硬盘、网络I/等，或top命令去监控，在点击执行；然后就能检测到性能参数；在收集的实际性能指标进行分析和预期指标进行对比。对比后分析性能问题，给出性能报告；最后在进行性能调优。
案例2:
性能测试或者压力测试你是怎么做的？
我们产品经理首先会评审性能需求，产品经理把需求分析过后，我们就根据需求做性能场景的设计，比如我就拿
登录-贷款资料录入-初审-回退-重新提交-复审-签约接口
这样的一个场景，和您这边大概说一下：
首先我会设计好这个性能测试用例之后，然后接着在Jmeter里面开始组建接口，把接口请求组建好之后，然后再添加吞吐量定时器，再添加TPS插件，HPS插件，以及混合图表，查看结果树，聚合报告，以及对应的一个并发线程数比如50，然后选择压测10分钟，然后就开始点击运行，进行压测，在压测过程当中，我一般会通过混合图表去看当负载不断升高的时候，也就是我的并发线程数，它负载升高的时候我的接口的响应时间跟我的TPS之间的一个曲线变化，当我的TPS到达最高点，响应时间开始急剧上升的时候，这个时候一般就会出现一些捌点或瓶颈点，那我们去看一下它后续的一个曲线变化是怎么样的，后续如果TPS没有很快的急剧上升而是平缓的运行，我们这个时候就会去看它的、监控它的TPS是否符合我们原来设定的那个TPS、因为之前我们计算得出来的TPS需要高于105笔/秒，但我压的时候平均都能达到300多TPS，TPS这块就是符合需求的，但是只关注这个标指标还不行，还需要关注这个接口它的平均响应时间是不是在3秒钟之内。0到1秒一般是比较优秀，说明这个接口响应时间必较快速，1到3秒合格，超过了3秒我这边就会调整并发或者rps并且重新去压，还有就是错误率。我们之前的错误率指标需要低于0.1%，如果错误大于了0.1%此时说明接口有很多的报错，也是不符合性能要求的， 直到我们压完之后如果TPS达标，接口平均响应时间达标，错误率达标之后。我们还需要在服务器端用top和iostat和dstat命令去监控它的cpu和内存，如果CPU和内存的使用率都能低于70%的话那就说明没问题，我会去输出性能测试报告，然后再发送报告给到我整个项目组