性能指标
一、性能测试指标
性能测试是通过测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。
目的：验证软件系统是否能够达到用户提出的性能指标，发现系统中存在的性能瓶颈并加以优化。
二、指标分为两大类：
软件指标，硬件指标
三、指标的时候收集：
（1）下载两个jia包
（2）存放路径
例如：E:\dcs\two\jmeter（14）\apache-jmeter-3.3\lib\ext 李静
显示jmeter插件
============================================
jmeter插件详解
监听器中的插件
@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 每秒点击次数 （hps）
@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 每秒事务数 （tps）
=========================================================
图标：
1、聚合报告
2、图像报告
3、表格查看结果
4、插件中jp@gc - Active Threads Over Time
每秒的活动线程数
x轴：访问时间 单位 ：ms
y轴：活动线程数 单位：个数
5、插件中jp@gc - 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％就中止测试
6、jp@gc - Bytes Throughput Over Time 字节吞吐量随时间变化
红色：每秒接受的字节数
蓝色：每秒发送的字节数
X轴：表示访问时间
Y轴表示每秒发送的字节数
7、jp@gc - Composite Graph 综合图
作用：在它的Graphs里面可以设置多少个图表一起展示，它可以同时展示多个图表；
目的：将一些图表结合在一起查看性能趋势和走向，有利于对比和结合查看性能情况，最重要分析性能拐点或瓶颈；
x轴：坐标是运行时间，
y轴：各性能数据的汇总值（其中有一些数据需要除以10）。
8、jp@gc - Connect Times Over Time 连接时间
9、jp@gc - Console Status Logger
这是一个简单的侦听器，它在JMeter以非gui模式运行时将简短的摘要日志打印到控制台。它还以GUI模式将相同的信息写入jmeter.log。
注意，打印的响应时间和延迟值是平均值。
10、jp@gc - DbMon Samples Collector
11、jp@gc - Graphs Generator 图形发生器
12、jp@gc - Hits per Second 每秒点击数 （简写：hps）重点：
x轴：访问时间
y轴： 每秒点击数
13、jp@gc - Page Data Extractor 页面数据提取器
14、jp@gc - PerfMon Metrics Collector （禁用） 性能指标收集器
15、jp@gc - Response Codes per Second 每秒响应数
在jmeter 测试期间，随着时间的而退应返回的响应码，从中我们可以看出测试期间在那个时间段内出现错误，可以分析在时间内系统的什么环节因素导致的错误
codes 是指请求的状态，如200，404,502等
总数：100个请求，每一秒成功数：
16、jp@gc - Response Latencies Over Time 随着时间间隔变化的响应延迟
义：记录客户端发送请求完成后，服务端返回请求以前这段时间，
表明jmeter 测试期间，随着时间的推移，系统的响应时间的变化，也是系统随着时间推移系统效率的变化
17、jp@gc - Response Times Distribution 响应时间分布图
18、jp@gc - Response Times Over Time 随时间变化的响应时间
19、jp@gc - Response Times Percentiles 响应时间百分位数
20、jp@gc - Response Times vs Threads 响应时间vs 线程
21、jp@gc - Synthesis Report (filtered) 综合报告
22、jp@gc - Transaction Throughput vs Threads 整个线程的事务数
23：jp@gc - Transactions per Second 每秒事务数（简写：tps） 重点
=========================================================
软件指标： 术语 释义
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原则推算,则(50000080%)/(820%3600)=69.4笔/秒，取整为70笔/秒，每年按业务量增长50%计算，则⼀年后系统处理能⼒指标约等于
70+7050%=105笔/秒。
第3个公式计算和第2个有点类似，但是加了一个冗余系数这个是为了后续业务增长做容量规划使用的，比如现在的系统需要支持105笔/秒，后续随着业务增加可以扩个2-5倍。
QPS（Query Per Second）是指单位时间内查询或访问服务器的次数。
计算公式和tps一样
一个tps肯能包含（一个或多个qps，访问服务器次数）
TPS和QPS的区别：
TPS和QPS的区别在于一个事务可以包含多次查询或访问服务器，也可以只查询或访问一次服务器。当多次查询或访问时，一个TPS相当于多个QPS；当只查询或访问一次时，一个TPS则等价于一个QPS。
============================================
错误率: 经系统处理的事务出现错误的概率，对应着实际用户使用系统功能失败的情况。理想情况下错误率应保持极低水平。
错误率=错误数/请求总数
2/100=0.02=2%
如：100个请求，错误2个请求，错误率达到2%
============================================
资源占用率 :服务器端各关键资源的使用比例，用于衡量系统硬件能力
例如
(1)服务器CPU利用率,
(2)磁盘利用率
(3)硬盘利用率等
资源利用率是分析系统性能指标进而改善性能的主要依据,
============================================
响应时间 :对请求作出响应所需要的时间
响应时间：响应时间=网络响应时间+应用程序响应时间=（N1+N2+N3+N4）+(A1+A2+A3)
标准可参考国外的3/5/10原则：
（1）在3秒钟之内，页面给予用户响应并有所显示，可认为是"很不错的"；
（2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是"好的"；
（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是"勉强接受的"；
（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；
标准可参国内2-5-8原则：
（1）2s内表示很好
（2）5s内可以
（3）8s勉强接受
（4）超出8s不行
响应时间满足258原则: S<=2s 优秀 2s<S<=5s 良好 5s<S<=8s 一般 S>8s Bug
平均响应时间 :所有请求平均花费的时间
如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms
平均响应时间： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms并不能反映服务器的整体效率，因为98个请求耗时才1ms，引申出百分位数
百分位数：以响应时间为例，指的是 99% 的请求响应时间，都处在这个值以下，更能体现整体效率
并发
并发是指多个用户在同一时期内进行相同的事务处理或操作。由于用户在进行一系列操作流程时有一定的时间间隔（即用户思考时间）或者服务器处理请求有先后顺序，于是，就产生了绝对并发和相对并发概念的区分。
绝对并发是指同一时刻（即同一时间点）并发用户对服务器同时发送请求。
相对并发是指一段时间内（即同一时间区间）并发用户对服务器发送请求
例如：批处理
==============================================
并发数 :测试时同时系统发出事务请求的数量，并发线程数用以模拟同时与系统建立连接的用户。
（1）第一种情况：并发数=线程数
（2）线程数和并发数不一致;
比如线程数10，并发5，每一次并发5个
并发用户数: 同时向系统发出事务请求的数量
并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的 操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行"严格意义上的并发"。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
并发主要是针对服务器而言，在同一时刻与服务器进行交互（指向服务器发出请求）的在线用户数。
===========================================
在线用户：指某段时间内，用户访问系统的用户数，如多个用户在浏览网页，但没有对同时对服务器进行数据请求，需要与并发用户数区分开。
============================================
最佳并发用户数：
最佳并发用户数：当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待
============================================
最大并发用户数：
最大并发用户数：系统的负载一直持续，有些用户在处理而有的用户在自己最大的等待时间内等待的时候
案例：
理发店模式，简单地阐述一下，一个理发店有3个理发师，当同时来理发店的客户有3个的时候，那么理发师的资源能够有效地利用，这时3个用户数即为最佳的并发用户数；当理发店来了9个客户的时候，3个客户理发，而6个用户在等待，3个客户的等待时间为1个小时，另外的3个客户的等待时间为2小时，客户的最大忍受时间为3小时包括理发的1个小时，所以6个客户的等待时间都在客户的可以承受范围内，故9个客户是该理发店的最大并发用户数
============================================
系统的平均负载：在特定的时间内，系统正在处理的用户数和等待处理的用户数的总和
============================================
峰值：指的是系统的最大能承受的用户数的极值
只有最大并发用户数的大于系统所能承受的峰值负载，才不会造成等待空间资源的浪费，导致系统的效率低下
如：10w用户，高峰 期晚上6：00-8：00
估算峰值：10w80% /(2606020%)=80000/1440=55.55 约等于56 每秒
============================================
事务：可以看作是一个动作或是一系列动作的集合，例如登录，从登录开始到登录结束为一个事务。
============================================
HPS（Hits per Second）：一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和
每秒点击数
第1秒点击95次
第2秒100次
第3次点击60次
点击率：单位时间每秒钟向web服务器提交的HTTP请求数
每秒钟用户向WEB服务器提 交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.
案例：
比如公众号的一篇文章被浏览了10w次，文章中的广告链接被点击了2000次，那么这条广告的点击率是2%（2000/100000*100%）
============================================
吞吐量 ：单位时间内处理的客户端请求数量
一个接口 ：公式：吞吐量=并发数/平均时间响应
多个并发：公式吞吐量：请求总数/实际时间
比如：
100个请求，时间运行时间12s ，吞吐量大约8.5
===========================================
吞吐率：单位时间（可以是秒/分/时/天）内网络成功传输的数据量，如请求数/秒、页面数/秒
吞吐量/传输时间,就是吞吐率.
100/12=8.5吞吐量
吞吐率：
①业务角度：单位时间（每秒）的请求数或页面数，即请求数/秒或页面数/秒；
②网络角度：单位时间（每秒）网络中传输的数据包大小，即字节数/秒等；
③系统角度，单位时间内服务器所承受的压力，即系统的负载能力。
============================================
吞入率 ：单位时间内从服务器返回的字节数，也可以单位时间内客户提交的请求数
============================================
TPS事务：服务器每秒处理的事务数衡量脚本中一行代码或多行代码的执行所耗费的时间
============================================
点击数：指Web Server收到的HTTP请求数
============================================
点击量：向web服务器提交的HTTP请求数
============================================
PV和UV是衡量web网站性能容量的两个重要度量指标，经常用在电子商务网站领域中用来衡量网站的活跃度。
PV（Page View）是页面的浏览量或点击量，用户对系统或者网站任何页面的每一次点击或者访问都会被记录一次浏览量或点击量，对相同页面进行多次访问浏览量或点击量也会进行累计。
============================================
UV（Unique Vistor）是系统或者网站的独立访客，一段时间内相同客户端（或PC）访问系统或者网站只会被记录一次，连续重复访问或者浏览多个系统页面次数不会进行累计。
PV和UV按照统计周期划分，可以划分为全天PV、每小时PV、全天UV和每小时UV等。在一些数据或交易量非常庞大的场景中，比如双11或618等全民购物活动时，常常还会统计峰值PV和峰值UV
============================================
二、硬件指标：
CPU
============================================
内存Memory，
内存：与cpu沟通的桥梁，计算机中所有程序的运行都在内存中进行，内存分为物理内存、页面交换（Paging），SWAP内存（虚拟内存）
============================================
磁盘I/O（Disk I/O），
磁盘吞吐量，指单位时间内通过磁盘的数据量。主要关注磁盘的繁忙率，如果高于70%，则磁盘瓶颈
============================================
网络I/O（Network I/O）
网络吞吐量，指单位时间内通过网络的数据量，当吞吐量大于网路设备或链路最大传输能力，即带宽时，则应该考虑升级网络设备或者增加带宽，Linux命令netstate
============================================
查看硬件 指标的命令
（1）cup：
命令1: cat /proc/cpuinfo //获取CPU详情
命令2: top //包含CPU、内存使用等情况，常用命令
（2）内存：
命令1： free --h 内存
命令1：uptime负载
命令3：#w
（3）磁盘
命令1: fdisk --l //查看硬盘及分区情况
命令2：df --h //查看文件系统的磁盘空间使用情况
（4）整体
命令：# vmstat 3 2 //每3秒一次，共2次
我们用nmon查看硬件指标
============================================
面试题：
1、你做过性能？你是怎么做性能？
做过，jmeter
2、你做性能测试关注哪些指标？
tps、吞吐量、响应时间、错误率、平均响应时间、并发数、
cup、内存、硬盘、网络
3、什么tps，tps怎么计算？
4、什么是吞吐量，吞吐量的计算？
5、性能中遇到的那些问题？如何解决？
案例1：某次压力测试，同样并发TPS,但前期性能良好，后期数据库CPU飙升
压测会产生大量级的数据，数据增长会带来性能的损耗
压测数据不合理，导致统一设备 关联多个用户，服务端不做限制的in查询
不合理分页，未做页数limit,导致将数据库新增数据全部查询
案例2：响应时间过长，什么原因怎么分析？
一般响应时间过长有下面几个原因：
（1）服务器硬件资源cpu，内存，磁盘达到瓶颈，可以使用监控命令排查
（2）网络问题导致，比如丢包，带宽不够等等
（3）线程出现死锁，阻塞等问题可以用jstack查看
（4）中间件比如mq消息队列拥堵排队等
（5）数据库层面sql不够优化，没有索引，联合索引失效等，数据库连接数不够。
案例3：压力测试中TPS一直上不去
这个原因比较多，压测整个链路上任何一个环节有瓶颈或者问题都有可能导致
首先是压力机压力不够，比如用我们笔记本基本压不到那么高TPS， 所以我们公司有自己的压测平台，分布式集群压测。
（1）网络带宽，单位时间内网络传输数据量过大，超过带宽处理能力
（2）数据库连接数太少，最大连接数不够
（3）Cpu，内存，磁盘硬件资源达到瓶颈
（4）中间件redis也有可能存在瓶颈比如缓存穿透，缓存过期等等
（5）存在大量线程阻塞，线程死锁等
（6）中间件消息队列拥堵
案例4:数据库CPU高
问题现象：后台指令发送满负荷工作时，数据库CPU高。
问题原因：后台指令发送线程每次对全量查询结果排序，结果集很大，然后取一条记录；索引区分度不高，满负荷执行时；查询频率很高；压测显示，并行发送指令的后台线程越多，数据库CPU越高，效率越低。
解决方法：
去掉ORDER BY，增加索引后，效果不明显。因为结果集大和查询频繁两个问题没有解决，因此考虑使用设计新的方案。
新方案：设计指令发送线程池，生产者线程每台任务服务器只有一个线程，负责查询待发送指令，每次查询50条指令。每条指令包装成一个Runnable对象，放进ThreadPoolExecutor线程池，线程池大小参数设置为100或200。每当线程池满时，生产者停止生产指令，休息15秒后继续。消费者线程即线程池里的线程，参数设置为4，8或12（和不同指令类型的指令数据量成正比）。
改进后的方案，数据库CPU降到10%一下，发送效率单机提升6倍，且可线性扩展任务服务器。
案例5：内存溢出（堆溢出、栈溢出、持久代溢出）
解决思路：1、调整堆内存参数，一般是增加堆内存
2、减少批处理数据量
案例5：
线程死锁：容量（压力）测试压测一段时间后，报连接超时
解决思路：
1、造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时 错误
2、找到死锁的线程，分析对应的代码
案例6：压测TPS曲线剧烈下降或抖动
问题现象：50并发压测，TPS曲线正常应该是平缓的，波动不大，如果突然出现剧烈下降，并且短时间内无法恢复，则可能存在问题。
问题原因：一般是由于前置或bp的jvm进行垃圾回收，或者日志记录磁盘满导致的。
解决方法：如果不是特别剧烈的波动或者TPS曲线下降后长时间不反弹，则可以忽略该问题。否则，需要分析曲线下降的时刻，系统当时正在发生的事情。可以通过top命令监控当时CPU占用比价高的线程，也可以kill -3 pid杀javacore来查看线程堆栈。
案例7：
CPU高
问题现象：50并发压测，监控工具显示bp、前置CPU占用90%以上。
问题原因：业务处理中存在大量CPU计算操作。
解决方法：采用更高效的算法、数据结构替换原来消耗CPU的代码，或者采用新的设计绕过瓶颈代码，比如查找数据的逻辑，可以把List改为Map，以空间换时间；比如用Json报文替换XML报文，提高传输、解析和打印日志的效率。
导致Cpu计算资源高消耗的代码：报文格式转换、加解密、正则表达式、低效的循环、低效的正则表达式。
排查方法：
压测进行时，使用jvisualvm工具远程连接应用，点抽样器àCPU，点快照生成线程快照。采样一段时间后，抽样器会显示各个方法占用cpu时间，可以针对CPU时间占用高的方法进行优化。
使用tprofiler，jprofiler，OracleDeveloperStudio12.6-linux-x86工具分别分析消耗CPU时间长的方法，以上工具分析结果可能有些差别。针对CPU计算耗时最长的方法进行优化。
案例8：内存泄漏
问题现象：JVM内存耗尽，后台日志抛出OutOfMemeryError异常 ；
问题原因：内存溢出问题可能的原因比较多，可能是全局的List、Map等对象不断被扩大，也可能是程序不慎将大量数据读到内存里；可能是循环操作导致，也可能后台线程定时触发加载数据导致。
解决方法：对于ibmjdk纯java应用，在jvm启动时设置-XX:+HeapDumpOnOutOfMemory Error参数，会在内存溢出时生成heapdump文件。使用ha456.jar工具打开heapdump文件，分析大对象是如何产生的。
当然，在heapdump中对象类型可能只是List这种结构，看不出具体哪个业务代码创建的对象。此时要分析所有的全局对象，列出可疑的List或Map对象，排查其溢出原因。
全局对象、引用的初始化、修改要慎重。建议应用梳理所有可能存放全局对象的代码，统一管控
案例9：打开了太多文件
问题现象：采用合理的并发数压测，交易失败，或后台日志报错：To many open files。
问题原因：
读取配置文件或者业务数据文件后，未关闭文件流；
/etc/security/limits.conf中***打开文件数配置过小。
解决方法：
使用lsof --p pid 命令查看进程打开的文件，如果大部分文件都是同一类型的文件，说明可能未关闭文件流。找到打开文件的代码，关闭文件流即可。
如果不存在未关闭文件流的问题，且业务本身就需要处理大量文件，则修改/etc/security/limits.conf文件如下内容：
hard nproc 10240
soft nproc 10240
案例10：
线程阻塞在日志记录上
问题现象：系统响应时间长、通过javacore查看很多线程阻塞在打印日志上。
问题原因：log4j1.x版本较低，性能较差；大报文日志多次输出。
解决方法：
减少无效日志、删除无用日志，减少大日志输出。
升级log4j组件到log4j2，参考log4j2官方文档，配置合理的日志缓冲区，采用高效的Appenders，比如RollingRandomAccessFile。但log4j2仍然采用同步日志，不采用异步日志。因为网银系统日志量较大，异步日志队列很快就满了，如果单条日志存在大报文，还有可能导致内存溢出，因此不适合采用异步日志。如果日志量少（压测产生日志的速度，低于日志写入文件的速度），则可以使用异步日志，大幅提高性能。如果日志量较大，则不建议使用异步日志。
排查方法：
JVM启动参数中增加-XX:+HeapDumpOnCtrlBreak，压测进行时，kill -3 pid 杀几个javacore，使用jca457.jar工具打开并分析。推荐使用该工具，因为该工具可以对所有线程状态进行统计，并生成饼状图，方便查看。
压测进行时，使用jvisualvm获取jvm快照，分析线程堆栈。
案例11、多线程并发问题
问题现象：采用合理的并发数压测，系统出现逻辑错误、交易失败或异常报错。经查是由于对象中变量被异常修改导致。
问题原因：系统中全局对象中的类变量或全局对象，被多个线程修改。
解决方法：排查系统中所有持有全局对象或类变量的代码，检查其全局变量是否可能被多个线程并行修改。
修改方法：
将全局变量转成方法内的局部变量；
对全局变量进行同步控制比如syncronized代码块，或者java.util.concurrent锁
排查方法：并发问题很可能是由全局变量或者对象导致，准确识别全局变量，通过阅读代码找问题。建议应用梳理所有可能存放全局对象的代码，统一管控，或者把所有全局对象放到一个类中，方便管理
案例12：
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
修改完成后重启生效