Once a Login script is executed with few user, I don't see connection reset problem, whereas, when the same is run 100 users, "java.net.SocketException: Connection reset" starts throwing for very first link.
What I don't understand is if there is connection problem, then it should even show the same error for single or few users as well.
This means that your server is rejecting connections because it is either overloaded or misconfigured.
It is regular that you don't face it with 1 user and face it with 100, this is typically what load testing brings, ie simulate traffic on your server
It might be the case described in Connection Reset since JMeter 2.10 ? wiki page.
If you are absolutely sure that your server is not overloaded and is configured to accept 100+ connections (defaults are good for development, not for production, they need to be tweaked) you can try work it around as follows:
In user.properties file add the next 2 lines:
httpclient4.retrycount=1
hc.parameters.file=hc.parameters
In hc.parameters file add the following line:
http.connection.stalecheck$Boolean=true
Both files live in JMeter's bin folder.
You need to restart JMeter to pick the properties up.
Above instructions are applicable for HttpClient4 implementation, make sure you use it, the fastest and the easiest way to set HttpClient4 implementation for all the HTTP Request samplers is using HTTP Request Defaults
Related
I need to perform a load test against a pgbouncer. All the clients perform an SSH Tunnel before enstablishing a database connection to the database (through the pgbouncer). It's something like this:
sshpass -p 'MY_PSW' ssh -o StrictHostKeyChecking=no -N -L LOCAL_PORT:127.0.0.1:63666 PGBOUNCER_USER#PGBOUNCER_ADDRESS -p PORT >/dev/null 2>&1 &
My Jmeter project has three thread Groups at the moment:
SetUp Thread Group: In which I make a connection to a different database to select a random username and schema
Query Thread Group: In which I perform the JDBC connection using the previous user (which became a property using props.put("schema", vars.get("schema_1")); into the BeanShell Assertion) and the queries
TearDown Thread Group: In which I close the ssh Tunnel.
Now every first time I run the test from the GUI, the data select (JDBC request) into the Query Thread Group gives me an error:
Cannot create PoolableConnectionFactory (FATAL: "trust" authentication failed)
After that, if I run the test again, everything works. I checked the content of the variables and properties with a Debug sampler and everything is correct.
The main problem starts when I run the test without the GUI. It always fails because of that error.
I actually don't like the fact that I have to enstablish the SSH tunnel running the command with an OS Process Sampler, but I can't find any better solution. The SSH tunnel is a part of the test, I don't need that for the master/slave configuration of JMeter.
I would appreciate a lot for a solution or a suggestion to make this work. Thanks.
If you're using the command in the OS Process Sampler it's being run in the background therefore my expectation is that the OS Process Sampler returns the SampleResult immediately and the tunnel is not up yet.
Then when the "Query Thread Group" starts as per JMeter Test Elements execution order JDBC Connection Configuration tries to establish the connection using local port which is not fully established. The fact that the issue is reproducible in non-GUI mode might be the confirmation for my guess as JMeter works much faster in non-GUI as it doesn't need to waste time and resources for GUI refreshing and propagating sample results to listeners.
My expectation is that if you add i.e. Flow Control Action sampler to the setUp Thread Group and configure it to "sleep" for a couple of seconds it should resolve your issue. If it doesn't - try increasing JMeter logging verbosity for the JDBC Test Elements by adding the next line to log4j2.xml file
<Logger name="org.apache.jmeter.protocol.jdbc" level="debug" />
and compare the entries for "successful" and "failed" executions in the jmeter.log file.
Ok, I managed to find the solution. Thank to Dmitri T Answer, I could track the problem, which was about the property not being properly set.
I was using the BeanShell Assertion to set the property after the result of the JDBC request in the setUp Thread Group. Apparently, the BeanShell Assertion is executed at the end of the entire run, so the property where being set at the end. During the first execution, the property is empty.
I used the Beanshell Sampler instead and now it works.
Noticed below error during load test with multiple users and not in case of single SOAP request.
Could not open JDBC Connection for transaction; nested exception is java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:
This could be due to any of the following:
The datasource connection pool has not been tuned (e.g. max-pool-size and blocking-timeout-millis) correctly for the maximum load on the application.
The application is leaking connections because it is not closing them and thereby returning them to the pool.
Threads with connections to the database are hanging and holding on to the connections.
Make sure that the min-pool-size and max-pool-size values for the respective datasource are set according to application load testing and connections are getting closed after use inside the application code.
Most likely you've found the bottleneck in your application, it seems that it cannot handle that many virtual users. The easiest solution would be raising an issue in your bug tracker system and let developers investigate it.
If you need to provide the root cause of the failure I can think of at least 2 reasons for this:
Your application or application server configuration is not suitable for high loads (i.e. number of connections in your JBOSS JDBC Connection pool configuration is lower than it is required given the number of virtual users you're simulating. Try amending min-pool-size and max-pool-size values to match the number of virtual users
Your database is overloaded hence cannot accept that many queries. In this case you can consider load testing the database separately (i.e. fire requests to the database directly via JMeter's JDBC Request sampler without hitting the SOAP endpoint of your application.) See The Real Secret to Building a Database Test Plan With JMeter article to learn more about database load testing concept.
Jmeter Environment Details
I am performing Jmeter testing on Microsoft Azure Cloud. I have created on VM(Virtual Machine) on the same cloud and from there I am hitting the application server on the same cloud environment. So in this case there is no network latency.
Problem Statement:
I am trying to run the load test for 300 users for 30 mins , but after 5 mins my script started failing, because of Socket connection refused error.
My Analysis based on information available on net:
I have read somewhere that this problem is because of limited socket connection limit on server, but when i run the same test from VM then my scripts run's just fine. so its definitely not server's issue. Can somebody please help me resolve this issue? Are there any settings needs to be done in jmeter, increase the socket connections?
Actual Screenshot of Error
enter image description here
Most likely:
Looks like situation described at Connection Reset since JMeter 2.10 ? wiki page. If you're absolutely sure that nothing is wrong with your server, you can follow the next recommendations:
Switch all your HTTP Request Samplers "Implementation" to be "HTTPClient4". The fastest and the easiest way of doing it is using HTTP Request Defaults.
Add the next lines to user.properties file (in JMeter's /bin folder)
httpclient4.retrycount=1
hc.parameters.file=hc.parameters
Add (or uncomment and edit) the following line in hc.parameters file
http.connection.stalecheck$Boolean=true
Alternative assumption:
"Good" browsers send "Connection: close" with the last request to the web server. "Bad" browsers don't and keep connection open. You can control this behaviour via "Use KeepAlive" checkbox in the HTTP Request Sampler/Defaults. If it's unchecked - you can try ticking it.
I can't figure this one out. I can't connect to a server using MySQL Workbench, I tried any kind of connection methods. The error message I get is
Failed to Connect to MySQL at AT 127.0.0.1:3306 with user root
Invalid for this platform protocol requested(MYSQL_PROTOCOL_SOCKET)
I ran into the same problem, in my case I originally created the connection with the "Local Socket/Pipe" option selected in the "Connection Method" drop down. Trying to switch back to "Standard (TCP/IP)" did not work and caused the error mentioned by OP. I had to delete the connection and start over by selection "Standard (TCP/IP)" from the start. The connection was successful after that.
To solve this problem you must check the "Others" field in Advanced tab
If you had the connection stored with a socket option you will find a "socket=." (or anything similar)
Delete it
e.g. http://prntscr.com/k63pua
This is a very unusal error message which I haven't seen before, especially on Windows. It has probably to do with how the server is installed. As a newbie it would definitely be the best choice to use the Windows Installer for all required parts. This will install the server properly too.
By using xampp you are on your own to check whether a server is installed and running as a service, as well as the proper configuration. For troubleshooting watch my video on Youtube where I tried to explain most common pitfalls for beginners.
Note: you can open the connection without actually being connected. In that case MySQL Workbench allows to do all those things that don't require a valid server connection, e.g. log file viewing, config file editing, service start/stop etc. Use this to check your server's configuration. Make sure it accepts TCP/IP connections (there's also a short section in the video about this).
Update:
Downvoter, please add a comment why you think my answer is bad.
Re-reading the error message I got another idea: could it be that you used local socket/named pipe for the connection? If so try with normal TCP/IP.
I am trying to connect to an external SOAP service using PHP and have written a small php test script that just connects to the service and performs a simple request to check everything is working.
This all works correctly but when I run via a browser request, it is very slow taking somewhere in the region of 40s to establish the initial connection. When I do the same request using the exact same script on the command line, it goes through straight away.
Does anyone have any ideas as to why this might be?
Cheers
PHP caches the wsdl in /tmp. If you run from the command line first, the cache file will be owned by whatever user you're running the script as, and apache won't be able to read the cache. The wsdl will have to be downloaded and parsed every time which will be slow.
Check the permissions of /tmp/wsdl*.
Maybe external SOAP service trying to check your IP, and your server has ICMP allowed, when your local network - not.
Anyway, this question might be answered more clearly by administrator of external SOAP service :)
Is there a difference between the php.inis that are being used?
On a standard ubuntu server installation:
diff /etc/php5/apache2/php.ini /etc/php5/cli/php.ini
//edit:
Another difference might be in the include paths. Had this trouble myself on a local test server, it didn't actually use the soap class that was included (it didn't include anything, because the search paths weren't valid), but it included the built-in soap_client class.