Jmeter的端口使用问题解析

       Jmeter的端口是通过Java的RMI技术实现的,大家都知道默认端口是1099,用到RMI即远程方法调用(Remote Method Invocation)的特性(支持存储于不同地址空间的程序级对象之间彼此进行通信,实现远程对象之间的无缝远程调用)。Java RMI 用于不同虚拟机之间的通信,这些虚拟机可以在不同的主机上、也可以在同一个主机上;一个虚拟机中的对象调用另一个虚拟上中的对象的方法,只不过是允许被远程调用的对象要通过一些标志加以标识。

RMI的交互图

       RMI由3个部分构成,第一个是rmiregistry(JDK提供的一个可以独立运行的程序,在bin目录下),第二个是server端的程序,对外提供远程对象,第三个是client端的程序,想要调用远程对象的方法。
       首先,先启动rmiregistry服务,启动时可以指定服务监听的端口,也可以使用默认的端口(1099,不做配置的话就是默认端口)。
       其次,server端在本地先实例化一个提供服务的实现类,然后通过RMI提供的Naming/Context/Registry(下面实例用的Registry)等类的bind或rebind方法将刚才实例化好的实现类注册到rmiregistry上并对外暴露一个名称。
       最后,client端通过本地的接口和一个已知的名称(即rmiregistry暴露出的名称)再使用RMI提供的Naming/Context/Registry等类的lookup方法从RMIService那拿到实现类。这样虽然本地没有这个类的实现类,但所有的方法都在接口里了,便可以实现远程调用对象的方法了。

       方法调用从客户对象经存根(stub)、远程引用层(Remote Reference Layer)和传输层(Transport Layer)向下,传递给主机,然后再次经传输层,向上穿过远程调用层和骨干网(Skeleton),到达服务器对象。

       说完这些,我们再来看看Jmeter,其实Jmeter有三个端口是我们需要关注的,一个是server_port(默认1099),这是每个压测节点(压测服务)都必须启用的端口,另一个是从节点(Slave/Server)的server.rmi.localport (默认是随机的,设置为0或不设置就表示随机),还有一个是主节点(Master/Client)的client.rmi.localport (默认也是随机的,设置为0或不设置就表示随机),由于后两端口都是随机的,所以我们一般不关注它们,但是如果是在防火墙下,或是Docker环境中,我们不允许端口随机,那就必须设置固定端口:

我们需要为每个从节点 或者 服务器打开2个端口(由主节点向从节点发送数据,所以这两端口有时候也可以同时设置成1099)。
Server_port=1099
server.rmi.localport=50000

可以在节点配置文件jmeter.properties中设置,也可以在启动节点时设置:

$JMETER_HOME/bin/jmeter-server \
                        -Dserver.rmi.localport=50000 \
                        -Dserver_port=1099

在客户端计算机上打开一个端口,以便从属服务器将结果发送给主服务器。
client.rmi.localport=60000

可以在主服务的配置文件jmeter.properties中设置,也可以在压测命令中配置(如果配置文件中这块也设置了端口,将以配置文件的为准):

jmeter -n -t sample-test/sample-test.jmx -Dclient.rmi.localport=60000 -R172.17.0.5,172.17.0.6,172.17.0.7

从上面的主从关系调用来看,也能明白端口的设置关系,但是如果我们严格按照以上的方式配置了,并且相应端口在防火墙下也放行了,是否就表示没问题了,不一定,我们还要结合日志对一些异常进行分析。

情况一:RMI开启了附加端口,导致防火墙下主节点传输端口还是不通

我们在master主控端设置了client.rmi.localport=60000的端口,但实际上当我们压测时,进程会再开启另外两个端口(60001和60002)。

为了确保压测顺利,这两个端口也应该在防火墙下放行,否则可能出现压测时卡着不动,如下日志:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/log4j-slf4j-impl-2.11.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/ext/jmeter-plugins-dubbo-2.7.3-jar-with-dependencies.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
Creating summariser <summary>
Created the tree successfully using weixin-Test.jmx
Configuring remote engine: 192.168.0.154
Using local port: 1099
Starting remote engines
Starting the test @ Thu Mar 25 08:52:37 CST 2021 (1616633557889)
Remote engines have been started
Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445

一般一直卡在Waiting中,就表示端口不通,要么是端口没完全开放(本例属于这种情况,只开放了60000,没有开放附加端口),要么是java.rmi.server.hostname没设置(在多网卡情况下,没设置hostname也可能会导致RMI连通信息被阻塞),我们可以看jmeter.log日志,发现没有异常,slave引擎正常启动:

2021-03-25 08:52:40,543 INFO o.a.j.r.RmiUtils: Disabling SSL for RMI as server.rmi.ssl.disable is set to 'true'
2021-03-25 08:52:40,543 INFO o.a.j.s.BatchSampleSender: Using batching (client settings) for this run. Thresholds: num=100, time=60000
2021-03-25 08:52:40,543 INFO o.a.j.s.DataStrippingSampleSender: Using DataStrippingSampleSender for this run
2021-03-25 08:56:55,186 INFO o.a.j.e.ClientJMeterEngine: sent test to 192.168.0.154 basedir='.'
2021-03-25 08:56:55,187 INFO o.a.j.e.ClientJMeterEngine: Sending properties {}
2021-03-25 08:56:55,193 INFO o.a.j.e.ClientJMeterEngine: sent run command to 192.168.0.154
2021-03-25 08:56:55,193 INFO o.a.j.e.DistributedRunner: Remote engines have been started

我们再到slave端看jmeter-server.log日志,发现被主节点拒绝连接了:

2021-03-25 08:56:55,179 INFO o.a.j.e.RemoteJMeterEngineImpl: Creating JMeter engine on host 192.168.0.154 base '.'
2021-03-25 08:56:55,179 INFO o.a.j.e.RemoteJMeterEngineImpl: Remote client host: 192.168.0.182
2021-03-25 08:56:55,180 INFO o.a.j.e.StandardJMeterEngine: StandardJMeterEngine Start ............................ 192.168.0.154
2021-03-25 08:56:55,182 INFO o.a.j.s.FileServer: Default base='/opt/apache-jmeter-5.1.1/bin'
2021-03-25 08:56:55,185 INFO o.a.j.s.FileServer: Set new base='.'
2021-03-25 08:56:55,189 INFO o.a.j.e.StandardJMeterEngine: Applying properties {}
2021-03-25 08:56:55,190 INFO o.a.j.e.RemoteJMeterEngineImpl: Running test
2021-03-25 08:56:55,193 INFO o.a.j.e.StandardJMeterEngine: Running the test!
2021-03-25 08:56:55,193 INFO o.a.j.s.SampleEvent: List of sample_variables: []
2021-03-25 08:56:55,197 INFO o.a.j.e.u.CompoundVariable: Note: Function class names must contain the string: '.functions.'
2021-03-25 08:56:55,197 INFO o.a.j.e.u.CompoundVariable: Note: Function class names must not contain the string: '.gui.'
2021-03-25 08:59:02,795 ERROR o.a.j.s.RemoteListenerWrapper: testStarted(host) on 192.168.0.154
java.rmi.ConnectException: Connection refused to host: 192.168.0.182; nested exception is: 
        java.net.ConnectException: Connection timed out (Connection timed out)
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) ~[?:1.8.0_171]
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129) ~[?:1.8.0_171]
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_171]
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_171]
        at com.sun.proxy.$Proxy20.testStarted(Unknown Source) ~[?:?]
        at org.apache.jmeter.samplers.RemoteListenerWrapper.testStarted(RemoteListenerWrapper.java:79) [ApacheJMeter_core.jar:5.1.1.20200917]
        at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:210) [ApacheJMeter_core.jar:5.1.1.20200917]
        at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:387) [ApacheJMeter_core.jar:5.1.1.20200917]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]
Caused by: java.net.ConnectException: Connection timed out (Connection timed out)
        at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:1.8.0_171]
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:1.8.0_171]
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:1.8.0_171]
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:1.8.0_171]
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:1.8.0_171]
        at java.net.Socket.connect(Socket.java:589) ~[?:1.8.0_171]
        at java.net.Socket.connect(Socket.java:538) ~[?:1.8.0_171]
        at java.net.Socket.<init>(Socket.java:434) ~[?:1.8.0_171]
        at java.net.Socket.<init>(Socket.java:211) ~[?:1.8.0_171]
        at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40) ~[?:1.8.0_171]
        at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) ~[?:1.8.0_171]
        ... 10 more
2021-03-25 09:01:10,027 ERROR o.a.j.s.RemoteListenerWrapper: testStarted(host) on 192.168.0.154
java.rmi.ConnectException: Connection refused to host: 192.168.0.182; nested exception is: 
        java.net.ConnectException: Connection timed out (Connection timed out)
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) ~[?:1.8.0_171]
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129) ~[?:1.8.0_171]
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_171]
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_171]
        at com.sun.proxy.$Proxy20.testStarted(Unknown Source) ~[?:?]
        at org.apache.jmeter.samplers.RemoteListenerWrapper.testStarted(RemoteListenerWrapper.java:79) [ApacheJMeter_core.jar:5.1.1.20200917]
        at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:210) [ApacheJMeter_core.jar:5.1.1.20200917]
        at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:387) [ApacheJMeter_core.jar:5.1.1.20200917]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]
Caused by: java.net.ConnectException: Connection timed out (Connection timed out)
        at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:1.8.0_171]
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:1.8.0_171]
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:1.8.0_171]
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:1.8.0_171]
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:1.8.0_171]
        at java.net.Socket.connect(Socket.java:589) ~[?:1.8.0_171]
        at java.net.Socket.connect(Socket.java:538) ~[?:1.8.0_171]
        at java.net.Socket.<init>(Socket.java:434) ~[?:1.8.0_171]
        at java.net.Socket.<init>(Socket.java:211) ~[?:1.8.0_171]

说明还是端口不通,明明我们开放了60000端口,但还是会出现拒绝连接的情况,怎么办呢?这时候只要把60001和60002端口也都同时开放,这个问题就可以解决。

以上是用我们的jmeter压测平台(https://smooth.blog.csdn.net/article/details/83380879)遇到的情况,实际上用jmeter脚本命令跑测(jmeter -n -t sample-test/sample-test.jmx -Dclient.rmi.localport=60000 -R192.168.0.154),也会发现进程开启了60001和60002来个端口,但却没有60000端口,说明60001-2这两个端口才是负责进行数据交互传输,如下所示:

在脚本命令模式下,压测任务结束后,这个60001和60002端口就会被释放。如果两个脚本任务同时进行,肯定也会出现端口冲突。但是用压测平台的api进程模式,就没有这个问题,多个任务可以共享这两个端口传输,但副作用就是60000-60002这三个端口一直不会释放(即使压测任务已经结束),除非重启平台服务进程。

以上的问题是在Jmeter5.1.1版本下遇到的,其他版本没试过不知道。

情况二:传输端口被占用,如命令模式下的slave多任务运行

由于我们固定了端口,带来的副作用是显而易见的,就是多个脚本同时调用不同slave节点压测时,还是会出现端口占用,一般压测时报以下错误,我们就要怀疑是否端口被占用了:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/log4j-slf4j-impl-2.11.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/ext/jmeter-plugins-dubbo-2.7.3-jar-with-dependencies.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
Creating summariser <summary>
Created the tree successfully using weixin-Test.jmx
Configuring remote engine: 192.168.0.154
Using local port: 1099
Starting remote engines
Starting the test @ Thu Mar 25 08:22:59 CST 2021 (1616631779725)
Error in rconfigure() method java.rmi.MarshalException: error marshalling arguments; nested exception is: 
        java.io.NotSerializableException: org.apache.jmeter.threads.RemoteThreadsListenerTestElement
Remote engines have been started
Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445

我们再看jmeter.log日志,就会发现端口占用的提示:

2021-03-25 08:23:00,023 ERROR o.a.j.e.ConvertListeners: Error replacing class org.apache.jmeter.threads.RemoteThreadsListenerTestElement by wrapper: class org.apache.jmeter.threads.RemoteThreadsListenerWrapper
java.rmi.server.ExportException: Port already in use: 60001; nested exception is: 
        java.net.BindException: 地址已在使用 (Bind failed)
        at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:254) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) ~[?:1.8.0_171]
        at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) ~[?:1.8.0_171]
        at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:236) ~[?:1.8.0_171]
        at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:383) ~[?:1.8.0_171]
        at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:346) ~[?:1.8.0_171]
        at java.rmi.server.UnicastRemoteObject.<init>(UnicastRemoteObject.java:225) ~[?:1.8.0_171]
        at org.apache.jmeter.threads.RemoteThreadsListenerImpl.<init>(RemoteThreadsListenerImpl.java:59) ~[ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.engine.ConvertListeners.addNode(ConvertListeners.java:64) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jorphan.collections.HashTree.traverse(HashTree.java:976) [jorphan.jar:5.1.1 r1855137]
        at org.apache.jmeter.engine.ClientJMeterEngine.runTest(ClientJMeterEngine.java:137) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:132) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:149) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.JMeter.runNonGui(JMeter.java:1089) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.JMeter.startNonGui(JMeter.java:991) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.JMeter.start(JMeter.java:563) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]
        at org.apache.jmeter.NewDriver.main(NewDriver.java:253) [ApacheJMeter.jar:5.1.1 r1855137]
Caused by: java.net.BindException: 地址已在使用 (Bind failed)
        at java.net.PlainSocketImpl.socketBind(Native Method) ~[?:1.8.0_171]
        at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) ~[?:1.8.0_171]
        at java.net.ServerSocket.bind(ServerSocket.java:375) ~[?:1.8.0_171]
        at java.net.ServerSocket.<init>(ServerSocket.java:237) ~[?:1.8.0_171]
        at java.net.ServerSocket.<init>(ServerSocket.java:128) ~[?:1.8.0_171]
        at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:45) ~[?:1.8.0_171]
        at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:345) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335) ~[?:1.8.0_171]

非常不幸呀,60001端口被占用,说明已经有别的压测任务在使用这个端口,这就是最大的矛盾点,在防火墙或docker下,我们要固定端口,可是固定了端口,就避免不了冲突,所以在这种情况下,我们就老老实实等前面的任务结束了,再去跑第二个压测任务。当然还有别的办法,每启一个压测任务就换一个端口(在防火墙下比较麻烦),或是采用jmeter的api模式压测,也就是我们的jmeter性能压测平台,当然更好的方式就是抛弃RMI方式,别用jmeter-server了(毕竟用jmeter slave服务总是避免不了要面对端口独占的问题),可以用MeterSphere模式(关于MeterSphere的架构理解,可以参考我的另一篇文章https://smooth.blog.csdn.net/article/details/108755477

情况三:Slave压测引擎忙(多任务争用同一个节点)

这种情况很普遍,其实就是RMI的特性,1099端口毕竟是一个jmeter-server进程独占的,如果一个host只启一个jmeter-server,一个任务占用了一个hostname:1099,另一个任务如果也调用,就冲突了,slave端的jmeter-server.log日志能看出拒绝连接:

Using local port: 1099
Created remote object: UnicastServerRef2 [liveRef: [endpoint:[192.168.0.154:1099](local),objID:[10d35633:17857843dfe:-7fff, -8945685160021410107]]]
Starting the test on host 192.168.0.154:1099 @ Mon Mar 22 09:22:36 CST 2021 (1616376156692)
java.rmi.ConnectException: Connection refused to host: 192.168.0.182; nested exception is: 
        java.net.ConnectException: 连接超时 (Connection timed out)
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129)
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
        at com.sun.proxy.$Proxy20.threadStarted(Unknown Source)
        at org.apache.jmeter.threads.JMeterThread.threadStarted(JMeterThread.java:727)
        at org.apache.jmeter.threads.JMeterThread.initRun(JMeterThread.java:719)
        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:250)
        at java.lang.Thread.run(Thread.java:748)

压测客户端master的jmeter.log日志能看出压测引擎忙的报错:

2021-03-25 08:42:27,462 INFO o.a.j.s.DataStrippingSampleSender: Using DataStrippingSampleSender for this run
2021-03-25 08:46:41,936 ERROR o.a.j.e.ClientJMeterEngine: Error in rconfigure() method 
java.lang.IllegalStateException: Engine is busy - please try later
        at org.apache.jmeter.engine.RemoteJMeterEngineImpl.rconfigure(RemoteJMeterEngineImpl.java:145) ~[ApacheJMeter_core.jar:5.1.1 r1855137]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357) ~[?:1.8.0_171]
        at sun.rmi.transport.Transport$1.run(Transport.java:200) ~[?:1.8.0_171]
        at sun.rmi.transport.Transport$1.run(Transport.java:197) ~[?:1.8.0_171]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_171]
        at sun.rmi.transport.Transport.serviceCall(Transport.java:196) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688) ~[?:1.8.0_171]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_171]
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687) ~[?:1.8.0_171]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_171]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_171]
        at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_171]
        at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283) ~[?:1.8.0_171]
        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260) ~[?:1.8.0_171]
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161) ~[?:1.8.0_171]
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_171]
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_171]
        at com.sun.proxy.$Proxy19.rconfigure(Unknown Source) ~[?:?]
        at org.apache.jmeter.engine.ClientJMeterEngine.runTest(ClientJMeterEngine.java:153) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:132) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:149) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.JMeter.runNonGui(JMeter.java:1089) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.JMeter.startNonGui(JMeter.java:991) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at org.apache.jmeter.JMeter.start(JMeter.java:563) [ApacheJMeter_core.jar:5.1.1 r1855137]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]
        at org.apache.jmeter.NewDriver.main(NewDriver.java:253) [ApacheJMeter.jar:5.1.1 r1855137]

       这个问题也是jmeter的通病(比如压测任务非正常停止,引擎就不会正常释放,再次调用就忙),但还好jmeter在大多情况下已经能够满足我们的需要,分布式节点就只做分布式压测的事(遇到异常就通通杀进程),多任务测试的事可以交给master/client自己来做,如果还想要做分布式+多任务的活,那就得抛弃目前这种RMI的client-server模式,采用MeterSphere那种模式(参考https://smooth.blog.csdn.net/article/details/108755477)。

       基本上我们搞懂了Jmeter的分布式压测原理,再结合以上的日志分析方法,Jmeter的端口问题就可以很好的解决和回避,不再为这种小事而抓狂了。

本文部分参考如下文章:

https://blog.csdn.net/bobozai86/article/details/102885068

http://testautomationguru.com/jmeter-distributed-load-testing-using-docker/

https://blog.csdn.net/zbj18314469395/article/details/104567655

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 酷酷鲨 设计师:CSDN官方博客 返回首页