发现性能瓶颈，优化的方式
时间节点：项目完成之后，上线之前，性能压测
发现许多系统瓶颈：数据库瓶颈、影响性能的代码、通用的配置上的一些问题（这些配置在平时都是不会关注的）
jmeter：apache 研发的基于java的性能压测工具，这个工具就是一个客户端，这个客户端集成了各种各样的接口，能够方便我们实现各种各样接口的逻辑去测试接口、webservice、double接口、数据库dao接口等等这种样子基于java的实现的一套机制的性能压测接口
jmeter 官网：jmeter.apache.org
所需要的东西：
线程组：压测高并发下系统的表现，jmeter提供线程组的工具，能够在jmeter内部启动多个并发的线程，并发的去发送一些接口的请求，用来测试服务端的压力
http 请求：线程组要做的事情就是在这个场景下发送 http 请求
查看结果树：等到有对应的 http 请求发送出去之后，需要查看对应http的返回结果，正常的？异常的？异常的话就有可能是容量不够所产生的拒绝连接等等这种样子的瓶颈
聚合报告：生成性能压测报告，内部含有TPS，QPS等性能评测的指标来表现对应接口的响应情况，还有一些99线95线等等
组装jmeter发送请求的线程池
同一时间起几个线程
Ramp-Up时间：1秒钟之内把20个线程都启动起来
循环次数：这20个线程每个线程循环多少次，发送多少个请求，
上图解释：会在10秒钟之内启动起来20个线程，并且让这20个线程每个线程都循环调用接口1次
完成线程组的设置之后，需要创建一个HTTP请求
用来做真正做压测一个接口 客户端的事情
http请求对应的协议默认就是 http
HTTP请求是被这个线程组当中的线程所调用，要发起的一个请求
然后还需要一个结果树
查看结果树、查看结果集的功能，查看成功多少，失败多少，并且有一个返回值
这个结果树当中会把对应的一个http接口返回的response都打印出来，可以选仅显示错误日志，仅显示成功日志
最后我们还需要有一个报告
有接口响应的平均值，中位数值，90线，95线，99线，最大最小值，Error，TPS，received sent的数据包大小
组装一次 http 请求，并且模拟压测一把对应的数据，看压测结果是否能够达到预期
就压测一个商品详情页的信息
高级->客户端实现->java
这是因为需要使用 KeepAlive，http 的KeepAlive，就是http 做长连接使用，不适用短连接，因为如果是压测接口大部分时候都耗性能耗在建立连接关闭连接上面，那这个性能其实是不能接受的，要压测的其实是这个接口 /item/get?id=6 的响应时耗，因此需要使用对应的http keepalive 将客户端和服务端保持一个长连接的状态，去直接压测对应的接口，这样就可以将网络建连的过程的消耗减少到最小
因为这个版本的 jmeter 只有选择了 java 的客户端实现 keepalive 才能生效
压测的节奏：现在相当于测试环境的压测，一个还没有上线的测试的部署机器，如果说要进入一个线上环境的压测，那一定把线程数慢慢的往上加，因为线上环境的压测是跟产线共有流量共用应用服务器以及共用数据库的，如果说压力太大影响正常用户，其实线上的压测很危险，当然还可以有一些线上的专门的压测集群，灰度压测环境等等这样的依靠镜像流量的方式把对应的压测流量拷贝过去
无论压测方案是怎么样的，首先调试一下压测脚本肯定是没有错的，因此一定要先将线程数设成1，小压一笔
TPS Throughput/sec：每秒钟可以支持 xxx 的tps的流量
单台机器，单个接口 在一个线程的环境下压测其实是让服务端感知不到压力的
在结果树上清空一下结果器
