一、引出问题点:
在做性能测试中,谈到网络问题时,其实,在没有特别说明的情况下,我们一般讲的都是HTTP协议下的网络瓶颈问题,那么对于这个问题,我们如何来分析呢?
举例说明:
计算机中的网络,跟我们现实生活中的交通网络,其实也是一个道理,可以类比。
例如:你从住的地方,到你公司上班,人的位置,在整个过程中发生了移动,就相当于我们网络中一个数据包进行了传输,我们可以这样类比,来剖析下这个移动过程:
首先,住的地方是已知的,住的很豪华,有非常多的门,你要去上班,从任意一个门出来都可以,但是门再多,它也是有一定数量的。
从门出来,你就会想,用什么样的交通工具,如果使用4个轮子的车子,那接下来就会选择道路,因为不同的道路,拥堵情况可能不一样。
现在,你开车到了公司楼下,你又会选择从哪个门进公司。如果时间紧,人又多,一窝蜂都挤到一个门,你小身板,可能就挤不进去,所以你可能会挑一个足够宽让你进去的门。
接下来,我们根据这个过程,分析下,影响我们上班过程的瓶颈有哪些?
门很多,但是总有个数量,万一门不够,是不是就出不去了?所以,这个出口门,可能会是个瓶颈。
交通工具和道路。不同的交通工具,速度不一样;道路等级、宽窄、流通量都会影响通行速度,都可能是瓶颈。
公司入口门,如果大家都在同一时间点从门口进来,是不是就会要排队,或者进不来,那这个入口门,也可能会是瓶颈。
进入公司后,要进入办公室,办公室的门宽度,是不是也可能是个瓶颈。
总结:现在,我们知道了影响我们上班是否迟会到的瓶颈了,其实,在我们网络性能分析中,也是类似的。用HTTP协议来规范网络通信,用TCP\UDP进行数据传输,它就是我们上班的交通工具。
TCP连接有四个组成元件:源地址、源端口、目的地址、目的端口。
(1)源地址:就是你自己机器的ip,相当于你住的地址,一般都是唯一的;
(2)源端口:就是发起通信的端口,就是你从家里出来的门,你发起一次通信,就会要先找一个端口,打开端口,从端口出去,然后关闭端口。
(3)目的地址:这个过程,作为常规的使用,完全没有问题,所以平常大家都不关注这个。
(4)目的端口:但是,端口是很多,也耐不住你使劲的‘造’啊(就像你家很豪华,门再多,也耐不住你浪费啊。)
总结:在我们性能测试时,就是使劲的‘造’,会打开大量的端口,处于占用状态,没有获得到端口的就出不去,从而就可能出现,端口不够用的情况。
即:现在明白网络性能的第一个可能的瓶颈是什么了吧!--->端口不够用!!!
二、源地址端口不够用
大家在公司日常用的更多的电脑就是Windows,那windows的电脑端口有多少呢?
我们可以先简单理解为端口总共有65535个,其中:
·0~1023(共1024个),为公认端口,紧密的绑定在一些特定服务上,如21端口就是FTP服务,80端口就是HTTP服务;
· 1024~49151(共48127个),为注册端口,松散的绑定于一些服务,如8080端口常常就用于绑定tomcat服务;
· 49152~65535(共16384个),为动态或私有端口。
(1)看了这样一组数据,知道在做性能测试时,你本机TCP通信最多能消耗多少个端口了吗?
即:实际上,一台电脑TCP通信端口应该是在16400+个,当然也不会超过太多。
(2)为什么不是16384,而是这样一个值呢?
即:因为‘注册端口’中有部分端口,也会用于tcp通信。所以在性能测试时,最大可用端口范围会稍微大一点。
看到这,是不是就特别想知道怎么查看Windows系统中,TCP端口连接占用情况呢?
Windows系统查看当前TCP连接数:
netstat-ano|find"TCP"/i/c
#netstat显示协议统计信息和当前TCP/IP网络连接情况
#-a显示所有连接和侦听端口
#-n以数字形式显示地址和端口号
#-o显示拥有的与每个连接关联的进程ID
#/i指定搜索不区分大小写
#/c对包含指定的信息进行计数,并显示总计
Linux查看当前tcp连接数的方法
netstat-ano|grep'tcp'|wc-l
现在已经知道如何实时查看了,那实际执行性能测试,如果出现源地址端口不够用,会出现什么样的问题表现呢?
Addressalreadyinuse:connect
java.net.BindException:Addressalreadyinuse:connect
atjava.net.DualStackPlainSocketImpl.waitForConnect(NativeMethod)
atjava.net.DualStackPlainSocketImpl.socketConnect(UnknownSource)
atjava.net.AbstractPlainSocketImpl.doConnect(UnknownSource)
atjava.net.AbstractPlainSocketImpl.connectToAddress(UnknownSource)
atjava.net.AbstractPlainSocketImpl.connect(UnknownSource)
atjava.net.PlainSocketImpl.connect(UnknownSource)
atjava.net.SocksSocketImpl.connect(UnknownSource)
atjava.net.Socket.connect(UnknownSource)
atorg.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75)
at......
虽然出现Addressalreadyinuse:connect这个问题,原因很多,但源地址端口不够用,就是其中一个常见的原因。
我们可以尝试如下方法调优:
方法一:
如果是使用jmeter进行性能测试,出现上述报错,可以直接去掉http取样器的【使用KeepAlive】复选勾。
方法二:
·打开系统的注册表-->找到[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]-->
· 看下右侧的配置信息-->有没有MaxUserPort配置项,有-->则修改值为65534(十进制)-->确定
· 没有-->则新增一个DWORD,name为MaxUserPort,value为65534(十进制)-->确定-->
· 重启系统
可以参考地址:https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/connect-tcp-greater-than-5000-error-wsaenobufs-10055
完成这一步,我们已经知道,我们的系统当前端口可用范围已经达到最大。
接下来,我们还需要知道,端口被使用后,如果我们能及时回收,再利用是不是能提高端口利用率,这样是不是就变相增加了端口了呢?
所以,第二个调优方法就是,释放、回收端口。
方法三:
·打开系统的注册表-->找到[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]-->
· 看下右侧的配置信息,有没有TcpTimedWaitDelay配置项有-->则修改值为10(十进制,10秒)-->确定
· 没有-->则新增一个DWORD,name为TcpTimedWaitDelay,value为30(十进制)-->确定
· 重启系统
可以参考地址:https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/tcpip-and-nbt-configuration-parameters
完成了这两步,我们就已经完成了发送方的网络调优。
第二段分析:现在,我们已经知道如何解决从家里出来可能的问题了,接下来,就是开车,去上班。把车开出来,
先经过一段引路,然后才能进入主干道,主干道通行一段距离后,下主干道,进入一段公司引路,再进入公司
其实,我们的网络数据传输,也可以这样类比,网络数据包要通过网卡,使用网络传输介质(如网线)在网络中进行传输,进过多次周转,找到目标服务器,通过服务器网卡,进入服务器内部。
由此可以分析出:
·发送方的网卡速率有10m、百兆、G兆网卡,如果网卡不行,可能成为瓶颈。
· 传输介质,有线、无线,有线的介质(如双绞线、同轴电缆、光纤)、路由的复杂度(如国内、国外)等等,都会影响传输速度,这个有可能成为瓶颈。
· 服务器接收数据的网卡速率,照样也可能成为瓶颈
c:\>pingke.qq.com
正在Pingke.qq.com[101.89.15.159]具有32字节的数据:
来自101.89.15.159的回复:字节=32时间=22msTTL=54
来自101.89.15.159的回复:字节=32时间=23msTTL=54
来自101.89.15.159的回复:字节=32时间=22msTTL=54
来自101.89.15.159的回复:字节=32时间=23msTTL=54
101.89.15.159的Ping统计信息:
数据包:已发送=4,已接收=4,丢失=0(0%丢失),
往返行程的估计时间(以毫秒为单位):
最短=22ms,最长=23ms,平均=22ms
通过ping对方的域名或ip,在性能测试同时,网络传输时延以及丢包情况。丢包或时延比较严重,那么说明网络已经阻塞,需要做上述瓶颈分析;如果没有丢包,时延也很低,说明网络比较正常。
三、网络传输通道瓶颈
Ⅰ、查看发起请求的机器网卡速率。如果是Windows10电脑,可以在“网络连接”>选中机器网卡,右键‘状态’>查看弹窗中的‘速度’。
Ⅱ、检查网络传输路由,Windows下执行:
c:\>tracert-dke.qq.com
通过最多30个跃点跟踪
到ke.qq.com[101.89.15.159]的路由:
1<1毫秒<1毫秒<1毫秒192.168.1.1
21ms1ms1ms175.8.48.1
35ms5ms5ms61.187.3.33
4***请求超时。
523ms23ms24ms202.97.19.141
624ms24ms24ms101.95.88.77
7***请求超时。
8***请求超时。
9***请求超时。
10***请求超时。
11***请求超时。
1222ms22ms22ms101.89.15.159
跟踪完成。
第1列,表示路由节点数量;
第2~4列,表示连接到每个路由节点的速度、返回速度、多次连接反馈的平均值;
最后的ip,代表路由地址。
从这个就能看出在哪个节点时间长,可能有优化空间。
Ⅲ、数据传输到服务器了,现在要查看服务器的网卡信息。
[root@localhost~]#ethtoolens33|grep"Speed"
Speed:100Mb/s
#ens33为网卡名称
通过这个命令,我们可以看到ens33这个网卡,目前设置的速度为100Mb/s,这个已经非常大了,如果这个值过低,可能就需要改大,可以执行:
ethtool-sens33speed1000
#将网卡的速度设置为1000Mb/s
现在我们知道如何查看确认我们数据传输通道的问题了。
显然,我们对于这个环节出现瓶颈,办法不是很多。就像我们上班的路,我们能在引路上想些办法,规划好行车路线,但是我们对于主干道,几乎无能为力。
?好了,现在网络数据包,已经到达服务器了。服务器,现在一般情况下,都是linux为主。所以,接下来,就要看linux中可能的瓶颈了。
四、目的地址端口瓶颈
其实我们的请求在服务器上,就是类似这样,非常多的请求来到服务器,最后都是通过某个端口,或者几个端口真正获取响应数据。
首先,我们得知道,一台机器,再强,也只能接收一定量的请求,这个数量是有最大值的,我们可以通过:
linux机器上查看允许的连接配置
[root@localhost~]#ulimit-a
corefilesize(blocks,-c)unlimited
datasegsize(kbytes,-d)unlimited
schedulingpriority(-e)0
filesize(blocks,-f)unlimited
pendingsignals(-i)7197
maxlockedmemory(kbytes,-l)16384
maxmemorysize(kbytes,-m)unlimited
openfiles(-n)65535
pipesize(512bytes,-p)8
POSIXmessagequeues(bytes,-q)819200
real-timepriority(-r)0
stacksize(kbytes,-s)8192
cputime(seconds,-t)unlimited
maxuserprocesses(-u)7197
virtualmemory(kbytes,-v)unlimited
filelocks(-x)unlimited
如果觉得这个配置的'maxuserprocess'和'openfiles'太小,可以修改/etc/security/limits.conf
[root@localhost~]#vim/etc/security/limits.conf
#添加如下
your_accountsoftnproc32768
your_accounthardnproc32768
rootsoftnproc32768
roothardnproc32768
your_accountsoftnofile16000
your_accounthardnofile16000
rootsoftnofile16000
roothardnofile16000
修改完后,maxuserprocesses就会改成32768,openfiles值变更为16000。
做完这波操作,就相当于你对公司的入口门进行了设置,根据你的需要调整了门的宽度。
五、服务器内部端口瓶颈
首先我们可以查看下你当前服务的端口连接数量:
netstat-ane|grep'端口'|grepESTABLISHED|wc-l
这个命令执行完后,你会获得一个数值,这个数量到达一定的峰值之后,就不会再增长了,当你测试结束的时候,这个峰值就会逐步降低。
其实,这就是我们服务的连接数量,而这个数量,是可以配置的。
如果你的服务是tomat,可以在tomcat的conten.xml中,配置:
<Executorname="tomcatThreadPool"namePrefix="catalina-exec-"maxThreads="150"minSpareThreads="4"/>
<Connectorexecutor="tomcatThreadPool"port="8080"protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443"acceptCount="1000"/>
<!---
name:该线程池的标记
maxThreads:线程池中最大活跃线程数,默认值200(Tomcat7和8都是)
minSpareThreads:线程池中保持的最小线程数,最小值是25
maxIdleTime:线程空闲的最大时间,当空闲超过该值时关闭线程(除非线程数小于minSpareThreads),单位是ms,默认值60000(1分钟)
daemon:是否后台线程,默认值true
threadPriority:线程优先级,默认值5
namePrefix:线程名字的前缀,线程池中线程名字为:namePrefix+线程编号
--->
修改maxThreads的值,就是在修改我们的最大峰值。
注意:maxThreads不是无限大的,越大-->相应的消耗的资源也会越多。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理