I am very new to Jmeter and need to perform a load testing of one SOAP request with 100 Authentication data. I tried the below approach, where I saved the authentication data in CSV file, using CSV Data Config parameterised and passed onto HTTP Authorisation Manager. I am able to sequentially test the SOAP request with all the user authentication data available in CSV, but I need to run concurrently, with all the 100 users. Thanks in advance.
I have 5 users authentication(username/password) in csv file
Set your Number of Threads to 100, and the Loop Count to 1.
Number of Threads has to do with the number of concurrent users that get run.
Loop Count has to do with how many times a user actually does your script.
Note that if your ramp-up is slower than your script time, some users will finish before your test reaches its full concurrency. Check this question for use with the scheduler.
In order to make all the requests to fire at the same time you need to add Synchronizing Timer to your test plan.
Increase "Number of Threads" to 100 on Thread Group level
Add Synchronizing Timer as a child of the SOAP/XML-RPC Request
Set "Number of Simultaneous Users to Group by" to 100
Make sure that CSV Data Set Config has following configuration:
"Recycle on EOF?" - true
"Stop thread on EOF?" - false
Thanks everyone for the quick answer. With the synchronizing timer had to modify "Sharing mode" option to "Current Thread Group" in http://jmeter.apache.org/usermanual/component_reference.html#CSV_Data_Set_Config.
Related
Im new to REST API testing, I want to do a load of an HTTP REST API, is there any possibility to do a 100 number of parallel HTTP request testing with Jmeter?
And also my request need a query params, can I provide a list of values to Jmeter and Jmeter can loop each request with one param form the list provided?
Appreciate your help.
JMeter executes requests as fast as it can, I don't fully understand your 100 number of parallel HTTP request stanza.
If you want 100 virtual users concurrently accessing your API endpoint: under Thread Group specify number of threads as 100 and set loop count to Forever or -1. In this case the actual number of requests per second will depend on your application response time
If you want to send 100 requests at exactly the same moment - use Synchronizing Timer
If you need to send 100 requests per second - use Precise Throughput Timer
For parameterizing your request with external data people normally use CSV Data Set Config
I have a Thread Group with 200 threads. I need to send out 200,000 api requests (with different HTTP request paths) concurrently. Does any of the Jmeter timer can accomplish this? Thank you for your help!
Your use case is not very clear, in order to send 200 000 concurrent requests you need the same amount of threads (virtual users) under Thread Group. Once done you can ensure that they are being executed at exactly the same moment in time by adding Synchronising Timer.
HTTP Request paths can be parameterised using i.e. CSV Data Set Config.
There are also Parallel Controller and Parallel Sampler plugins which you can consider as an alternative, you can install them using JMeter Plugins Manager
I'm testing a web app using jmeter for load test and I getting a hard time on how can I set properly how many threads, ramp-up and loops will I use in order to get a large number of rps. Anyway, I want to check if my server can keep up to 500rps. Does anyone here can help me how can I set it properly. Thanks.
The number of requests per unit of time is called Throughput and mainly depends on two factors:
Number of active threads
Your application response time
The first one is obvious - more threads -> more requests per second. However JMeter will wait for response from the previous thread before starting the next request so application response time matters as well.
So the recommendations are:
Set number of threads in the Thread Group to the number of anticipated users of your system.
Set ramp-up period accordingly to the number of threads so the load will increase (and decrease) gradually, this way you will be able to correlate increasing/decreasing load with the changing response time and throughput
Instead of loops it might be a better idea to set desired test duration using Scheduler section of the Thread Group.
Run your test and observe the actual throughput using i.e. Server Hits Per Second listener or Transactions per second chart of the HTML Reporting Dashboard. If it matches your expectations - you are done, if not - you will need to increase the number of virtual users.
You can use ConcurrencyThreadGroup plugin , Specifically see how to Produce Desired RPS:
Threads pool size can be calculated like RPS * <max response time> / 1000. The more rate desired the more threads you will need. The more response time service have the more threads you will need.
For example, if your service response time may be 2.5sec and target
rps is 1230, you have to have 1230 * 2500 / 1000 = 3075 threads.
I'd like to know what Marketo means by 10 concurrent API calls. If for example 20 people use an API in the same time, is it going to crash ? And if I make the script sleep for X seconds if I get that limit response and try the API call again, will it work ?
Thanks,
Best Regards,
Martin
Maximum of 10 concurrent API calls means, that Marketo will process only 10 simultaneous API requests per subscription at maximum.
So, for example if you have a service that directly queries the API every time it is used, and this very service gets called 11 or more times in the same time, than Marketo will respond with an error message for the eleventh call and the rest. The first 10 calls should be processed fine. According to the docs, the error message the following requests will receive will have an error code of 615.
If your script is single threaded (like standard PHP) and you have more that 10 API calls, and your script is running in one instance, than you are fine, since the calls are performed one after another (so they are not concurrent). However, if your script can run in multiple instance you can hit the limit easily. In case a sleep won't help you, but you can always check the response code in your script and retry the call if it received an error. This retry process is often called Exponential Backoff. Here is a great article on this topic.
My JMeter load test includes a setUp thread group that makes 190 http requests to my test environment prior to running my test thread groups. This results in a spike of requests at the beginning of the test that appear to be included in the results of the load test. The results for average throughput are higher than they would be without the setUp thread group traffic. Is there any way to exclude the setUp thread group from the test results?
There are several options:
Synthesis Report plugin allows to set telemetry start and end offset values so you will be able to filter out unneeded data
You can add Listener of your choice to 2nd Thread Group - it will record only samplers in its scope.
You can run your JMeter tests via Taurus tool - the report will come in fancy web interface where you can zoom to the report part you need.
Which Listener/Reporter do you use to check your results?
Some reporters can show you not only average throughput but also split it by requests or threads. So, you can rename your SetUp requests using one label and just exclude these values from your total. Don't know how to do it using built-in methods but you can easily export your result table data as a file or just operate it using scripting.
If you just want to prevent spike on your graph, then use Constant Throughput Timer for your SetUp thread. It will slow down your request sending (by increasing delays between them) to meet defined throughput.
If your recording catches extra "http requests" which are not required , Click on "Add Suggested Excludes" or else can exclude by defining , so that will not come in your Result Analysis.