一、压力测试

压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内，做到心中有数。
使用压力测试，我们有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是: 内存泄漏，并发与同步。
有效的压力测试系统将应用以下这些关键条件:重复，并发，量级，随机变化。

1、性能指标

1.1 响应时间（Response Time: RT）：
响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响 应结束，整个过程所耗费的时间。
1.2 HPS （ Hits Per Second） ：每秒点击次数，单位是次/秒。
1.3 TPS （Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
1.4 QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。
对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一 般情况下用 TPS来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表 示对服务器单击请求。
无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：
ü 金融行业：1000TPS~50000TPS，不包括互联网化的活动
ü 保险行业：100TPS~100000TPS，不包括互联网化的活动
ü 制造行业：10TPS~5000TPS
ü 互联网电子商务：10000TPS~1000000TPS
ü 互联网中型网站：1000TPS~50000TPS
ü 互联网小型网站：500TPS~10000TPS
1.5 最大响应时间（Max Response Time ）指用户发出请求或者指令到系统做出反应（响应） 的最大时间。
1.6 最少响应时间（Mininum ResponseTime）指用户发出请求或者指令到系统做出反应（响应）的最少时间。
1.7 90%响应时间（90% Response Time）是指所有用户的响应时间进行排序，第90%的响应时间。
从外部看，性能测试主要关注如下三个指标：
1）吞吐量： 每秒钟系统能够处理的请求数、任务数。
2）响应时间： 服务处理一个请求或一个任务的耗时。
3）错误率： 一批请求中结果出错的请求所占比例。

2、JMeter执行压测

线程组参数详解：
Ø 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里 也就是设置多少个线程数。
Ø Ramp-Up Period(in seconds)准备时长： 设置的虚拟用户数需要多长时间全部启动。如果 线程数为10 ，准备时长为 2 ，那么需要 2 秒钟启动 10 个线程，也就是每秒钟启动 5 个 线程。
Ø 循环次数： 每个线程发送请求的次数。如果线程数为 10，循环次数为 100，那么每个线 程发送100 次请求。总请求数为 10*100=1000 。如果勾选了“永远” ，那么所有线程会 一直发送请求，一到选择停止运行脚本。
Ø Delay Thread creation until needed：直到需要时延迟线程的创建。
Ø 调度器： 设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为 永远)
Ø 持续时间（秒） ：测试持续时间，会覆盖结束时间
Ø 启动延迟（秒） ：测试延迟启动时间，会覆盖启动时间
Ø 启动时间： 测试启动时间，启动延迟会覆盖它。当启动时间已过，手动只需测试时当前 时间也会覆盖它。
Ø 结束时间： 测试结束时间，持续时间会覆盖它。

优化一：

3、结果分析

有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；<br />Throughput 吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加； 若在压测的机 器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；<br />    压测结束，登陆相应的web 服务器查看 CPU 等性能指标，进行数据的分析;<br />    最大的tps ，不断的增加并发数，加到 tps 达到一定值开始出现下降，那么那个值就是 最大的 tps。<br />    最大的并发数： 最大的并发数和最大的 tps 是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。<br />    压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu 、网络和 cpu 都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。<br />    影响性能考虑点包括：<br />数据库、应用程序、中间件（tomact 、Nginx ）、网络和操作系统等方面<br />    首先考虑自己的应用属于CPU 密集型还是 IO 密集型

4、JMeter Address Already in use 错误解决

4.1 报错原因：
1、windows系统为了保护本机，限制了其他机器到本机的连接数.
2、TCP/IP 可释放已关闭连接并重用其资源前，必须经过的时间。关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期（2MSL）状态。此时间期间，重新打开到客户机和服务器的连接的成本少于建立新连接。减少此条目的值允许 TCP/IP 更快地释放已关闭的连接，为新连接提供更多资源。如果运行的应用程序需要快速释放和创建新连接，而且由于 TIME_WAIT 中存在很多连接，导致低吞吐量，则调整此参数。

4.2 修改操作系统注册表
1、打开注册表：运行-regedit
2、输入找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters
3、右击Parameters新建 DWORD32值，name：TcpTimedWaitDelay，value：30（十进制） ——> 设置为30秒回收（默认240）
4、新建 DWORD值，name：MaxUserPort，value：65534（十进制） ——> 设置最大连接数65534
注意：修改时先选择十进制，再填写数字。
5、重启系统

二、性能监控

1、jvm 内存模型

2、堆

从Java8 开始，HotSpot 已经完全将永久代（Permanent Generation）移除，取而代之的是一 个新的区域—元空间（MetaSpace）

3、jconsole与jvisualvm

Jdk 的两个小工具 jconsole、jvisualvm（升级版的 jconsole）;通过命令行启动，可监控本地和 远程应用。远程应用需要配置

4、监控指标

4.1 中间件指标

4.2 数据库指标

5、JVM 分析&调优

jvm调优，调的是稳定，并不能带给你性能的大幅提升。服务稳定的重要性就不用多说了， 保证服务的稳定，gc 永远会是 Java 程序员需要考虑的不稳定因素之一。复杂和高并发下的服务，必须保证每次 gc 不会出现性能下降，各种性能指标不会出现波动，gc 回收规律而且干净，找到合适的 jvm 设置。Full gc 最会影响性能，根据代码问题，避免 full gc 频率。可以适当调大年轻代容量，让大对象可以在年轻代触发 yong gc，调整大对象在年轻代的回收频次，尽可能保证大对象在年轻代回收，减小老年代缩短回收时间




调优项官方文档：
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BGBCIEFC

三、thymeleaf模板

四、Nginx动静分离

由于动态资源和静态资源目前都处于服务端，所以为了减轻服务器压力，我们将js、css、img等静态资源放置在Nginx端，以减轻服务器压力。
Ø 静态文件上传到：mydata/nginx/html/static/index

Ø 修改index.html的静态资源路径，加上static前缀：如src=”/static/index/img/img_09.png”

Ø 修改/mydata/nginx/conf.d/default.conf

Ø 如果遇到有/static为前缀的请求，便会转发至html文件夹
Ø 细节：

五、Nginx实现反向代理

1、实现原理

本机浏览器请求gulimall.com，通过配置hosts文件之后，那么当你在浏览器中输入gulimall.com的时候，相当于域名解析DNS服务解析得到ip 192.168.56.10，也就是并不是访问java服务，而是先去找nginx。什么意思呢？是说如果某一天项目上线了，gulimall.com应该是nginx的ip，用户访问的都是nginx
1、请求到了nginx之后：
如果是静态资源/static/直接在nginx服务器中找到静态资源直接返回
如果不是静态资源/（他配置在/static/的后面所以才优先级低），nginx把他upstream转交给另外一个ip 192.168.56.1:88这个ip端口是网关gateway
在upstream的过程中要注意配置proxy_set_header Host $host;
2、请求到达网关之后，通过url信息断言判断应该转发给nacos中的哪个微服务（在给nacos之前也可以重写url），这样就得到了响应

2、Nginx配置文件

3、Nginx + 网关配置

Ø 修改主机hosts，映射gulimall.com到192.168.56.10。关闭防火墙
Ø 修改nginx/conf/nginx.conf，将upstream映射到我们的网关服务

Ø 修改nginx/conf/conf.d/default.conf，接收到gulimall.com的访问后，如果是/，转交给指定的upstream，由于nginx的转发会丢失host头，造成网关不知道原host，所以我们添加头信息

Ø 配置gateway为服务器，将域名为**.gulimall.com转发至商品服务。配置的时候注意网关优先匹配的原则，所以要把这个配置放到后面

监听来自gulimall:80的请求，

对于以/static开头的请求，就是找 /usr/share/nginx/html这个相对路径。为什么找那个？因为我们映射了docker外面的/mydata/data/nginx/html某一列到这个目录，所以在docker中就是去这找静态资源
其他的请求，转发到http://gulimall 这个upstream ，并且由于nginx的转发会丢失host头（host头是HTTP1.1开始新增的请求头），造成网关不知道原host，所以我们添加头信息

4、启动nginx容器

docker run --name nginx -p 80:80 
    -v /mydata/nginx/conf/nginx.conf:/etc/nginx/conf/nginx.conf 
    -v /mydata/nginx/log:/var/log/nginx 
    -v /mydata/nginx/conf.d/default.conf:/etc/nginx/conf.d/default.conf 
    -v /mydata/nginx/html:/usr/share/nginx/html -d nginx

开机自启动：docker update nginx —restart=always

5、遇到的问题