While running Jmeter in non-gui mode for 100 users for the first time after the restart of the server, it shows an "Internal Error" message for a single save thread (other 99 save threads have passed).
This error is when run for the first time.Later it passes 100 users any N number of times.
But when the same is done in manual testing (ie; saving 100 users) there is no error.
What could be the issue.
According to RFC 7231
6.6.1. 500 Internal Server Error
The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.
In general all HTTP status codes 5xx indicate a server error, so there is nothing to do with your JMeter script, you need to look into your server logs to identify the root cause of the issue on the server side.
It might be the case that the server gets overloaded and cannot handle 100 concurrent users due to one of the following reasons:
incorrect configuration of the server infrastructure (application server, database configuration settings, etc.), make sure that all the components of your application are properly configured for high load
lack of resources (CPU, RAM, Network and/or Disk IO, swap, sockets, etc.), make sure to monitor essential resources usage during the test execution, it can be done using i.e. JMeter PerfMon Plugin
it might also be the case your application uses inefficient or too complex algorithms, it worth running a test with performance profiling tools telemetry enabled, this is probably the best way of identifying the bottleneck
Related
We are executing a test of Upload scenario where we are aware that the response time will be more than 5 minutes. Hence we have configured timeout in HTTP Request Defaults as well as in the Http request as 3600000 milliseconds. But still we are getting Socket Exception in Upload transaction . Could you please suggest how to handle this.
Thanks,
SocketException doesn't necessarily means "timeout", it indicates that JMeter is not able to create or access Socket connection, there are too many possible reasons, the most common are:
Network configuration of your server doesn't allow that many connections as you're trying to open, check the maximum number of open connections on your application server and operating system level.
Your application server is overloaded and cannot handle such a big load. Make sure it has enough headroom to operate in terms of CPU, RAM and especially Network metrics (these can be monitored using JMeter PerfMon Plugin)
You might be experiencing the behaviour described in JMeterSocketClosed article
Basically the same as points 1 and 2 but this time you need to check JMeter health, make sure you're following JMeter Best Practices and maybe even consider going for distributed testing
I am doing some benchmark testing. During this, I have to increase numbers of users 3000, keeping ramp-up time 100 and loop count 1.
Somehow jmeter giving the below errors:
Response code: Non HTTP response code: org.apache.http.conn.HttpHostConnectException
Response message: Non HTTP response message: Connection to https://the-homepage-I-am-testing.net refused
There is no such thing as "JMeter5.5" yet, the latest version as of now is JMeter 5.1
Looking into error details it looks like a bottleneck on the application under test side so you need to inspect what's causing these connections refusals:
inspect your application logs for any suspicious entries, it might be a matter of a thread pool maximum setting which is not sufficient
inspect your application server / database configuration as it might be the case you have the above limitation on the middleware level
inspect OS configuration for the same as it might be the case there is not enough maximum open handles so OS cannot allocate a socket to serve the connection
make sure to monitor baseline health metrics, application under test should have enough headroom to operate in terms of CPU, RAM, etc. - you can use JMeter PerfMon Plugin for this
Looking into your configuration it doesn't necessarily assume 3000 concurrent users as you have only 1 iteration. Given 100 seconds ramp-up it might be the case that some users have already finished test execution and some had not been yet started. Double check you're really deliver the anticipated load using i.e. Active Threads Over Time listener.
I'm performing load test in my application which is registration application for schools.
So I'm performing load test for the registration scenario and when I perform load test with JMeter for 350 concurrent users using Thread group with 1 ramp up secs , I'm facing the below issue's ,
Timeout performing EVAL
500 - The request timed out.
502 - Internal server error.
Can any one suggest on this whether it is issue from JMeter tool or the issues is from the application side.
Normally HTTP Status Codes 500 and above indicate server-side error so most probably your application under test is not capable of handling 350 concurrent users, so basically you've found the bottleneck.
Next actions would be identifying
So called saturation point - the maximum number of users which your application can support before performance starts degrading (response time increases and throughput decreases)
Breaking point - you can state that 350 users are not supported, however I don't think you have information how many are really supported before the application starts throwing errors
The cause of the bottleneck which might be in:
incorrect configuration of the application and middleware - can be checked by manual inspection of configuration files and logs
lack of resources (i.e. CPU, RAM, Swap, Disk, Network, etc.) - can be checked using i.e. JMeter PerfMon Plugin
error in the application (inefficient algorithm, large objects, not closed handles, etc.) - can be checked using profiler tools
I am load testing an e-commerce site. Under medium to heavy loads, Jmeter reports an unusually high number of errors, i.e. succes=FALSE in the resulting .csv file which translates to a fairly high % errors in the JMeter dashboard report.
On inspecting the Kibana logs, other than a few WARN, there aren't any errors and the status for all the http requests are 200. In fact, I am able to verify that the test users created in my flow are able to login and view whatever the test was supposed to do.
My question is - how is JMeter determining this error (non-200 ?) when the server side returns nothing but 200? For fewer threads, the errors are 0%.
First I would check if any assertions can fail for any reasons. So disabling any assertions and running most primitive version of the script without any possibility of failure (other than based on sampler response) would be my first step. If it doesn't help...
HTTP Sampler will fail for return code < 200, or return code >= 400, or any Java exception, which will happen when request could not be sent, or response from the server was not received (in full). Most commonly those are timeouts related to various underlying problems:
Lack of available ports on JMeter side. Since you indicated that problem happens only with more JMeter users, it is a possibility. On paper you have 65535 ports, but both Windows and Linux are limiting number of available ports to few thousands by default. Make sure you have enough ports to run the load, and monitor port usage as you ramp threads up.
Even if all ports are available, many ports may be sitting for a few minutes in TIME_WAIT or CLOSE_WAIT state, depending on how your client and server interact and other network issues. So theoretically you may have 65k ports, but practically you don't have enough. In this case it's worth checking why it happens (can point to a bug) and possibly reduce the time ports will be waiting in this *_WAIT state.
You also need to make sure you have enough RAM, JVM heap and CPU: monitor to see if there's a bottleneck that can cause such slowness that breaks the ability of a Sampler to finish its work successfully.
If all of the above is working as expected, then either server or someone between client and server (load balancer, proxy, firewall) is causing this issue.
I would start from the server, and verify that all requests you are sending are received by a server. E.g. if you send 2000 requests, and server receives 1000, which finish successfully, then from server perspective everything is fine, but Jmeter will be at 50% error rate.
Also check your JMeter log definitions and make sure failures and exceptions are written to them properly (they are multi-line messages, and may cause log definitions to break when getting to them, and thus you wont' see them). For example run HTTP Sampler that points to non-available server. See if you can diagnose what returned exception was.
Beyond that - figuring out which part is "lying" to you would be an approach, but hard to offer any more specific advice based on current information
Getting high Error% in jmeter after run, how to know this error is due to out of memory or used machine doesn't have capability or the http request has an issue. In my case getting Error% in jmeter summary report is 97.50% (for login api) and when loaded this result in 'View results tree' can see 500 internal server errors or the failed requests. Please suggest what measures can be taken to analyse these errors.
As per the RFC 2616
10.5 Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.
10.5.1 500 Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.
So the possible reasons are in:
You are sending incorrect requests which cannot be processed on your server side. Check server logs for details, most probably you will be able to figure out something from them. If you don't have access to logs you can at least configure JMeter to save response data for failed requests, add the following lines to user.properties file to trigger this on:
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.response_data.on_error=true
Check out Configuring JMeter chapter for more information.
It may be your application components configuration which is not suitable for high loads, i.e. your application server or database can be configured to accept not more than X connections and your load test is exceeding this value. The solution is again to check application, web server and database logs and make required configuration changes
It may be due to simple lack of resources, i.e. CPU or RAM on server side so you can monitor them using u.e. JMeter PerfMon Plugin. See How to Monitor Your Server Health & Performance During a JMeter Load Test for more details.