-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP resources fails at a lower concurrency than expected. #6666
Comments
In my machine issues doesn't happen in 2201.4.3 |
The JMX script using a stepping thread group to identify the maximum concurrent threads which can be handled by the server without a timeout. There seems to be some interruption errors in the jmeter client side. Will get a thread dump for further analysis |
The issue here is the jmeter plugin client's behaviour. I saw that regardless of In the above screenshot, the very first request is coming as a HTTP/1.1 upgrade but the next request is a normal HTTP/1.1 request. Also there is a unexpected Due to these factors, the number of established connections are keep increasing since the ballerina server side does not limit the connections made by the client. So, there is an interruption exception occurred in the client used in the jmeter plugin. As the core jmeter does not have a HTTP/2 client, it is not advisable to trust the results of these plugins without verifying its behaviour. We recommend to use #!/bin/bash
URL="http://localhost:8080/hello"
TOTAL_REQUESTS=100000
INITIAL_CONCURRENCY=1
MAX_CONCURRENCY=200
STEP=1
for ((c=$INITIAL_CONCURRENCY; c<=$MAX_CONCURRENCY; c+=$STEP))
do
echo "Running with concurrency: $c"
h2load -n $TOTAL_REQUESTS -c $c $URL
sleep 2 # Pause between steps, adjust as necessary
done |
Keeping this issue open, to check the server's behaviour when we get an unexpected |
From my observation, this GO_AWAY comes after 20s. Looks like the client is just holding and closing it after a set timeout. |
At the moment, ballerina service does not act to the
However, this can cause issues with malformed clients. @TharmiganK observed something similar to this with the above client. Here, the client opens a connection and do some communication and send a |
Improved the behaviour by handling the |
Description:
HTTP resources fail at a lower concurrency than expected. It fails around 30 threads on my laptop, while similar java application can tolerate more than 200 (could be even higher).
Steps to reproduce:
create a simple service
Stress test with JMeter. test-bal-threads.txt (rename .txt to .jmx)
Affected Versions:
Ballerina 2201.9.1
Related Issues (optional):
https://discord.com/channels/957996897782616114/1017493204326686860/threads/1255528309769506969
The text was updated successfully, but these errors were encountered: