bzm - http2 sampler number of connections

[heysarthak]

Hi,

I was using http2 sampler 2.0.2, in which i am not able to control number of connections made with the server. if the number of threads are decreased, connections are decreased. But so does the performance of load testing.
is there a way to make controlled number of connections with the server per sampler.
i checked 2.0.2-alpha-3 release, it is not well documented yet so cannot find my use case over there.

[3dgiordano]

Hi @heysarthak

Each thread has its own http client and each http client manages connections according to the http specification.

When each thread terminates, it sends that thread's client to recycle, thereby closing connections that will not be used again.
Connections are also recycled based on whether the server sent them to shut down or if their idle timeout expires.

The http2 plugin supports multiplexing, so multiple requests can be sent on the same connection as opposed to how JMeter's http1 implements it, where for each request it uses a different connection.

To allow requests to run in parallel, you must group them in a new controller element "HTTP2 Controller" available in the alpha version. The requests that are incorporated there will run in parallel and take advantage of the multiplexing benefit.
Otherwise they will run in sequence (as JMeter's HTTP1 does), but reusing the connections that have not been invalidated by the server or by the idle timeout.

There are multiple properties that allow you to adjust the configuration of the http client, but we need to know exactly what you mean by connections in order to see which case should be adjusted.

It would be convenient for you to explain a little more in detail about the problem you are detecting.
You can use a proxy like Charles proxy to capture and share connection information to us as well as what you would expect.
You can show us the same flow or cycle in a real browser to compare behaviors.

Regards
David

[heysarthak]

I am currently running the whole setup on cloud based infra with Kubernetes,
Avg load on server is around 115,000 transactions per second.

on running the sample request, i can find the total number of connections to 20 nodes on which the server pods are deployed are around 1400+
The command i am using to get the number of ports linked is

ps -aef |grep 'java' |grep '-router'|awk '{print "sudo nsenter -t " $2 " -n netstat -nap | grep :8080"}'|sh | awk '{print $4}'|grep '8080'|wc -l

i did try changing httpJettyClient.minThreads to 30 or 50, but anyhow i was facing this error.

2023-06-06 13:00:35,693 ERROR o.a.j.s.BatchSampleSender: sampleOccurred
java.rmi.ConnectException: Connection refused to host: ; nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:626) ~[?:?]
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:217) ~[?:?]
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:204) ~[?:?]
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) ~[?:?]
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:215) ~[?:?]
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:160) ~[?:?]
at jdk.proxy2.$Proxy19.processBatch(Unknown Source) ~[?:?]
at org.apache.jmeter.samplers.BatchSampleSender.sampleOccurred(BatchSampleSender.java:182) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.samplers.DataStrippingSampleSender.sampleOccurred(DataStrippingSampleSender.java:106) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.samplers.RemoteListenerWrapper.sampleOccurred(RemoteListenerWrapper.java:94) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.ListenerNotifier.notifyListeners(ListenerNotifier.java:58) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.notifyListeners(JMeterThread.java:1037) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:591) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:501) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:268) ~[ApacheJMeter_core.jar:5.5]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.Net.connect0(Native Method) ~[?:?]
at sun.nio.ch.Net.connect(Net.java:579) ~[?:?]
at sun.nio.ch.Net.connect(Net.java:568) ~[?:?]
at sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588) ~[?:?]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327) ~[?:?]
at java.net.Socket.connect(Socket.java:633) ~[?:?]
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:304) ~[?:?]
at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:163) ~[?:?]
at sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88) ~[?:?]
at org.apache.jmeter.rmi.SSLRMIClientSocketFactory.createSocket(SSLRMIClientSocketFactory.java:117) ~[ApacheJMeter_core.jar:5.5]
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:620) ~[?:?]
... 15 more

[heysarthak]

my plan have 4 thread groups - ultimate thread groups and the structure looks like this

[3dgiordano]

Hi @heysarthak

1 - The stack it's related to a failure in JMeter RMI communication in JMeter distribute mode.

2 - Currently only recommended use native Thread Group from JMeter.

There are other solutions that use thread creation as a solution to trying to simulate concurrency in a JMeter not intended for asynchronous execution.

The http2 plugin using the http2 controller supports asynchronous execution, but requires that the main thread created by JMeter's Thread Group not be recreated or manipulated, as it maintains state at the thread level.

Other solutions may interfere with that and you may end up creating more instances of the HTTP2 client than you should.
In JMeter's HTTP1 you would not notice because for each request the http client is created and destroyed, but in the BZM plugin of http2 it is required to maintain state information at the thread level, that's why I recommend the use of the Default Thread Group on JMeter.

My recommendation is to first start simulating http2 execution using asynchronous execution with the http2 controller inside a JMeter thread group.
When you have a local functional execution, try scaling it in distributed mode with JMeter.

[heysarthak]

As per your suggestion, i used the thread group by jmeter. I am processing 4 request with a good amount of payload.
I am getting the following error.

it is not observed when i am performing it with v2.0.2 alpha 3, not while i am performing the same test with the same payload with v2.0.2

[3dgiordano]

Hi @heysarthak

The HTTP error 413 Request Entity Too Large it's a server-side control, usually related to the file size limit on upload but in some web frameworks or web servers also it's used in other size limits like "body size limit".

It must be analyzed on the server side what is related or associated with the 413 error, it is possible that it is used by some other type of control of size limits.