应用性能是产品用户体验的基石，性能优化的终极目标是优化用户体验。当我们谈及性能，最直观能想到的一个词是“快”，哪到底怎么才是快呢？如何又为慢！
性能优化
FPS是体现页面顺畅程度的一个重要指标。
12306购票案例查询按钮的设计
阿里云：5台4C8G机器，4台压力机2C4G
服务器环境：1台压力机，1台应用服务主机，1台数据库与缓存服务器，1CICD服务器
内网ip：172.17.187.81（I/O优化）25Mbps峰值
内网ip：172.17.187.78（I/O优化）25Mbps峰值
内网ip：172.17.187.79（I/O优化）25Mbps峰值
内网ip：172.17.187.80（I/O优化）25Mbps峰值
网络中的Mbps和MBps，及两者的换算关系
Mbps=Megabitpersecond(Mbit/sorMb/s)
MBps=Megabytepersecond
1Mbps=0.125MB/s
25Mbps=3.125MB/s
什么是压测？
压力测试（英语：Stresstesting）是针对特定系统或是组件，为要确认其稳定性而特意进行的严格测试。会让系统在超过正常使用条件下运作，然后再确认其结果。
压力测试是对系统不断施加压力，来预估系统服务能力的一种测试。
为什么对系统压测呢？有没有必要。压不压测要看场景！
一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行压力测试。
目的是什么？
压测性能指标有哪些？
在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。
三条曲线：
三个区域：
两个点：
三个状态描述：
常用压测工具：
JMeter压测环境架构图：
压测目标总的来说有4条：
ApacheJMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java小服务程序、CGI脚本、Java对象、数据库、FTP服务器，等等。JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
目标：完成压测案例，评测SpringBoot项目的吞吐量（TPS）上限。
步骤：
实现：
线程属性说明：
选择keepalive方式，表示使用了长连接。使用长连接可以防止频繁的建立连接，关闭连接消耗性能。一般浏览器都支持keepalive，如果这里不勾选，这样我们的压测的部分性能消耗会发生在建立，关闭连接上，导致我们的压测数据不准确。
（2）配置响应断言：我们接口正常返回code值为20001，如果接口返回code值不是20001表示接口异常，为了测试，这里修改为接口返回code值不为20001则表示访问失败。
配置监听器：监听压测结果【聚合报告和汇总结果很类似，看一个就行】
样本（sample）:发送请求的总样本数量
异常（error）:出现错误的百分比，错误率=错误的请求的数量/请求的总数
吞吐量（throughout）:吞吐能力，在这里相当于TPS
ReceivedKB/sec----每秒从服务器端接收到的响应数据量
SentKB/sec----每秒从客户端发送的请求的数量
记录了样本中的每一次请求
图形结果：分析了所有请求的平均值、终止、偏离值和通吐量之间的关系
横坐标：为请求数量，单位个数
吞吐量TPS（throughout）:吞吐能力，这个才是我们需要的并发数
每秒接收KB/sec----每秒从服务器端接收到的数据量
每秒发送KB/sec----每秒从客户端发送的请求的数量
平均字节数
线程组常用来模拟一组用户访问系统资源（API接口）。假如客户机没有足够的能力来模拟较重的负载，可以使用JMeter的分布式测试功能，通过一个JMeter的Master来远程控制多个JMeter的Salve完成测试。
已有内容的分析维度不够：需要加入新的插件
开启插件下载：
在线下载方法如下图所示：
常见的插件如下：
2）压力机活动线程数
压力机活动线程数表明压测过程中施加的压力的情况
3）TPS：每秒的事务数
数字愈大，代表性能越好；
4）QPS：每秒的查询数量
数字愈大，代表性能越好；（1tps>=QPS）
5）吞吐量：每秒的请求数量
压测的时候，我们需要实时了解服务器【CPU、内存、网络、服务器Load】的状态如何，哪如何监控服务器的资源占用情况呢？方法有很多种：
监控原理：
注意：服务器硬件资源的监控，必须在服务端安装serverAgent代理服务，JMeter才能实现监控服务端的cpu、内存、io的使用情况。
好处：可以将所有信息汇总到JMeter工具中来，查看非常方便。
服务器上执行以下命令：
#查询服务器资源使用情况toptop-H如下图所示，可以看到系统负载loadaverage情况，1分钟平均负载，5分钟平均负载，15分钟平均负载分别是0.08,0.03,0.05；
统计信息区前五行是系统整体的统计信息：
好处：不依赖环境，操作系统自带的命令，随时可以查看。
弊端：无法记录历史数据，不能看到变化的趋势
怎么理解系统资源的指标呢，怎么理解系统负载呢？
1）服务器：CPU、内存、网络IO
CPU
内存
网络IO
在类Unix系统中，系统负载是衡量计算机系统执行的计算工作量的指标。
不同的CPU性质不同：单核，双核，四核-->>
举例说明：把CPU比喻成一条（单核）马路，进程任务比喻成马路上跑着的汽车，Load则表示马路的繁忙程度。
情况1-Load小于1：不堵车，汽车在马路上跑得游刃有余：
情况2-Load等于1：马路已无额外的资源跑更多的汽车了：
情况3-Load大于1：汽车都堵着等待进入马路：
如果有两个CPU，则表示有两条马路，此时即使Load大于1也不代表有汽车在等待：
[Load==2，双核，没有等待]
如下分析针对单核CPU
如下分析针对单核CPU的三种情况：
举例：5.18,0.05,0.03
短期内繁忙，中长期空闲，初步判断是一个“抖动”或者是“拥塞前兆”
举例：5.18,1.05,0.03
短期内繁忙，中期内紧张，很可能是一个“拥塞的开始”
情况3：1分钟负载>5，5分钟负载>5，15分钟负载>5
举例：5.18,5.05,5.03
短中长期都繁忙，系统“正在拥塞”
情况01-模拟低延时场景，用户访问接口并发逐渐增加的过程。
线程梯度：5、10、15、20、25、30、35、40个线程
循环请求次数5000次
测试总时长：约等于20msx5000次x8=800s=13分
配置断言：超过3s，响应状态码不为20000，则为无效请求
应用服务器配置：4C8G
外网-网络带宽25Mbps（峰值）
内网-网络带宽基础1.5/最高10Gbit/s
集群规模：单节点
服务版本：v1.0
数据库服务器配置：4C8G
Mbps:Megabitpersecond(Mbit/sorMb/s)MB/s:Megabytepersecond1byte=8bits1bit=(1/8)bytes1bit=0.125bytes1megabyte=10002bytes1megabit=10002bits1megabit=0.125megabytes1megabit/second=0.125megabytes/second1Mbps=0.125MB/s配置监听器：应用服务器：内存、网络、磁盘、系统负载情况
MySQL服务器：内存、网络、磁盘、系统负载情况
进一步提升压力，发现性能瓶颈
聚合报告
ActiveThreads
RT
TPS
此时就是到了重负载区
压测监控平台与JMeter压测结果一致
压了13分钟，产生了5G的数据，按照我们的阿里云服务器配置，相当于三四块钱没了
压测中服务器监控指标
注意：系统网络带宽为25Mbps
优化方案：
方案01-降低接口响应数据包大小（把不应该推送给用户的优化掉）
返回数据量小的接口，响应数据包0.6kb，请求数据包0.421kb
htp://123.56.249.139:9001/spu/goods/10000023827800方案02-提升带宽【或者在内网压测】
25Mbps-->100Mbps（但是会变贵）
云服务器内网：这里在Linux中执行JMeter压测脚本
jmeter-n-t02-jmeter-example.jmx-l02-jmeter-example.jtl所以就是，想要高并发，money得有才行。
方案03-CDN
买CDN，给用户离他最近的流量
优化之后：
方案01-降低接口响应数据包大小，压测结果
问题：可不可以基于RT与TPS算出服务端并发线程数？
服务端线程数计算公式：TPS/(1000ms/RT均值)
结论：
//慢接口@GetMapping("/goods/slow/{spuId}")publicResultfindGoodsBySpuIdTwo(@PathVariableStringspuId){ Goodsgoods=spuService.findBySpuId(spuId); //模拟慢接口 try{ //休眠500ms TimeUnit.MILLISECONDS.sleep(500); }catch(InterruptedExceptione){ e.printStackTrace(); } returnnewResult(true,StatusCode.OK,"查询成功",goods);}响应慢接口：500ms+，响应数据包3.8kb，请求数据包0.421kb
htp://123.56.249.139:9001/spu/goods/slow/10000005620800测试结果：RT、TPS、网络IO、CPU、内存、磁盘IO
Tomcat的默认线程数是200
可以理解为与IO模型有关系，因为当前使用的是阻塞式IO模型。这个问题我们在服务容器优化部分解决。
因为是使用的是NIO，阻塞了之后我们前面配置的是超过3s就会报错，所以报异常了。
使用JMeter做大并发压力测试的场景下，单机受限与内存、CPU、网络IO，会出现服务器压力还没有上去，但是压测机压力太大已经死机！为了让JMeter拥有更强大的负载能力，JMeter提供分布式压测能力。
如下是分布式压测架构：
注意：在JMeterMaster节点配置线程数10，循环100次【共1000次请求样本】。如果有3台Salve节点。那么Master启动压测后，每台Salve都会对被测服务发起10x100次请求。因此，压测产生的总样本数量是：10x100x3=3000次。
搭建JMeterMaster控制机和JMeterSalve施压机
搭建注意事项：
与Window中安装JMeter一样，略
（1）下载安装
#1.改ipvimjmeter-server#RMI_HOST_DEF=-Djava.rmi.server.hostname=本机ip#2.改端口vimjmeter.properties#RMIporttobeusedbytheserver(muststartrmiregistrywithsameport)server_port=1099#Tochangethedefaultport(1099)usedtoaccesstheserver:server.rmi.port=1098（3）配置rmi_keystore.jks
（4）启动jmeter-server服务
（2）Salve启动，并监听1099端口。
（3）在JMeterMaster机器安装目录bin下，找到jmeter.properties文件，修改远程主机选项，添加3个Salve服务器的地址。
remote_hosts=172.17.187.82:1099,172.17.187.83:1099,172.17.187.84:1099