压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内，做到心中有数。
使用压力测试,我们有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：内存泄漏，并发与同步。
有效的压力测试系统将应用以下这些关键条件:重复，并发，量级，随机变化。
- 响应时间(Response Time: RT)
- 响应时间指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。
- HPS (Hits Per Second） :每秒点击次数，单位是次/秒。
- TPS ( Transaction per Second):系统每秒处理交易数，单位是笔/秒。
- QPS (Query per Second）:系统每秒处理查询次数，单位是次/秒。
- 对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPs来衡量接口查询次数，用HPS来表示对服务器单击请求。
- 无论TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下:
- 金融行业：1000TPS - 50000TPS，不包括互联网化的活动
- 保险行业：100TPS - 100000TPS，不包括互联网化的活动
- 制造行业：10TPS ~ 5000TPS
- 互联网电子商务：10000TPS - 1000000TPS
- 互联网中型网站：1000TPS - 50000TPS
- 互联网小型网站：50OTPS ~ 10000TPS
- 最大响应时间（(MaxResponse Time）指用户发出请求或者指令到系统做出反应(响应)的最大时间。
- 最少响应时间(Mininum ResponseTime）指用户发出请求或者指令到系统做出反应(响应)的最少时间。
- 90%响应时间（90% Response Time）是指所有用户的响应时间进行排序，第90%的响应时间。
- 从外部看，性能测试主要关注如下三个指标
- 吞吐量：每秒钟系统能够处理的请求数、任务数。
- 响应时间：服务处理一个请求或一个任务的耗时。
- 错误率：一批请求中结果出错的请求所占比例。
下载地址：https://archive.apache.org/dist/jmeter/binaries/
1.3.1 测试步骤
1、添加线程组
2、设置线程组参数
3、添加http请求和一些监听器
4、配置http请求参数
5、测试并查看结果
windows本身提供的端口访间机制的间题。
Windows 提供给TCP/IP链接的端口为1024-5000，并且要四分钟来循环回收他们。就导致我们在短时间内跑大量的请求时将端口占满了。
- cmd中，用regedit命令打开注册表
- 在HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters 下，
- 右击parameters，添加一个新的DWORD，名字为MaxUserPort
- 然后双击MaxUserPort，输入数值数据为65534，基数选择十进制（如果是分布式运行的话，控制机器和负载机器都需要这样操作哦)
- 继续添加一个新的DWORD，名字为TCPTimedWaitDelay，设置值为十进制30
- 修改配置完毕之后记得重启机器才会生效
Jdk的两个小工具jconsole、jvisualvm(升级版的jconsole);通过命令行启动，可监控本地和远程应用。远程应用需要配置
监控内存泄露，跟踪垃圾回收，执行时内存、cpu分析，线程分析…
- 运行:正在运行的
- 休眠: sleep
- 等待:wait
- 驻留:线程池里面的空闲线程
- 监视:阻塞的线程,正在等待锁
启动 Jvisualvm
cmd输入Jvisualvm启动，前提是你系统路径里设置的jdk下有Jvisualvm
在Jvisualvm里选择工具 -> 插件，进入可用插件点击检查更新版本
如果显示连接出错，则到http://visualvm.github.io/pluginscenters.html网站选择对应的jdk地址到设置里
安装完成后打开Visual GC
测试的线程组配置
3.1.1 nginx测试
http请求配置
打开linux下的docker检测：
3.1.2 gateway测试
http配置
3.1.3 简单服务
创建hello方法，路径：com/atguigu/gulimall/product/web/IndexController.java
重启服务
JMeter测试
3.1.4 gateway+简单服务
配置网关，加上 /hello，重启服务
JMeter测试
3.1.5 全链路测试
3.1.6 首页压力测试
3.1.7 三级分类数据测试
这个测试一直出不来数据，可能是因为吞吐量太小了，50个线程数有点处理不过来，把线程数调成10后再测试，发现有数据了，吞吐量只有 57/min…
3.1.8 首页全量数据测试
基本配置
高级配置
- 中间件越多，性能损失越大
- 业务：
- DB
- 模板渲染速度
- 静态资源
- 以后将所有的静态资源放在Nginx里面
- 规则：/static/** 所有请求都由nginx直接返回
分离步骤：
- 在linux虚拟机的 /mydata/nginx/html 目录下新建目录 static。
- 将静态资源 index 目录放到上面创建的文件夹下
- index.html 页面里的静态资源路径都加上static前缀
- 配置nginx，修改，重启nginx
- 访问http://gulimall.com/查看效果
3.4.1 全量数据获取测试
测试动静资源分离后的product模块性能
1、线程数设置50
2、基本http设置为首页
3、高级http设置
4、product模块开启缓存
5、JMeter测试
3.4.2 内存崩溃测试
1、设置product模块最大内存
2、设置测试线程数为 200
3、进行压测
测试结果：内存溢出，服务崩溃
不建议测试，看看就好
3.4.3 大内存测试
1、设置product服务内存：，-Xmn：设置Eden区域的内存大小
2、测试线程数设置为200
3、其他参数不变进行测试
思路：原来我们在（路径：com/atguigu/gulimall/product/service/impl/CategoryServiceImpl.java）方法中嵌套查询了数据库，将它改进为先查询出所有分类保存为一个集合，接着到这个集合中查询相关联的分类，这样就避免了重复查询数据库
修改后的方法：
3.5.1 测试优化后的性能
1、修改product服务的内存大小，改回100m：
2、设置线程数为50
3、修改http配置
4、测试结果对比