I have tried but have a doubt that whether the below-mentioned specification is equivalent to 4000load or not.
the number of threads-100,
ramp-up period-10 secs,
loop count- 40, then
which is equal to how much load??
You are loading 100 concurrent threads, the loops just adds more execution time.
So it isn't equivalent to 4000 concurrent threads hitting your server
I don't know what do you mean by 4000load, your test will send 4000 requests per each Sampler which is in your Thread Group as fast as it can. The actual test duration will depend on your application response time but will not be less than 10 seconds.
You might want to take a look at Transactions per Second and Server Hits per Second charts to see how many requests your configuration delivers, both charts can be installed using JMeter Plugins Manager
Also you can generate HTML Reporting Dashboard which will have consolidated aggregate view of your test results.
Related
In Jmeter I have a scenario like
Load tested with 4000 users and 1 hour duration
759965 requests made and out of which one request failed on an average 18894.13 requests made per second.
This was the earlier scenario and I want to make the same scenario again with the above information. Can someone guide me how to set up the environment and also the results. I have designed my script using Co-relation with the help regular expression extractor.enter image description here
For the normal Thread Group the configuration would be something like:
It would also be a good idea to use some ramp-up period so the load would increase gradually and you could correlate increasing load with other metrics like response time or transactions per second.
You might also want to use one of Custom Thread Groups which can be installed as JMeter Plugins, they provide easy visual way to define the number of threads, test duration, ramp-up, ramp-down, time to hold the load, eventual spikes, etc.
Once you define your desired workload you should run your test in command-line non-GUI mode, with regards to the test results the easiest option is to generate HTML Reporting Dashboard
So I'm working on JMeter and I tried to run a test plan (with only one script: edureka.co that further has 6 scripts when viewed in Result Tree like https://www.edureka.co/-0 https://www.edureka.co/-1 till https://www.edureka.co/-5) with concurrency thread group with 100 threads, 200 sec Ramp-up time and 2 Ramp-up steps. I ran this test plan in Non-GUI Mode of JMeter and to my surprise I got 7880+ records in my CSV File. Max I should have gotten like 600 records.
Anyone can tell why I'm getting this much records in my CSV file and what does the scripts https://www.edureka.co/-0, https://www.edureka.co/-1, https://www.edureka.co/-2 till https://www.edureka.co/-5 mean. (they show up even with 1 thread)
For these -0, -1, etc. there is an explanation:
first couple is being caused by redirection to https://www.edureca.co
next requests stand for images, scripts and styles - so called "embedded resources"
this is absolutely normal as long as JMeter sends the same requests as the real browser does, the only piece of advice I can give is to add HTTP Cache Manager to your test plan as real browsers download these embedded resources only once.
Max I should have gotten like 600 records - this is not true, the number of "records" depends on the application response time and related metrics (connect time, latency, network bandwidth, etc). If you want to limit the number of results to 600 only either switch to normal Thread Group with 100 threads and 6 loops or use Throughput Controller to limit the number of requests to 600 only
While understanding concept of Concurrent thread and ultimate thread group, i am confused to understand result of summary/aggregate report while running concurrent thread or ultimate thread group .For example if i have 200 user and ramp up time 60 sec then i didn't see all sampler request as 200 sample after completing execution successfully but only few sampler request have 200 sample. when i use normal thread group then i always got thread count same for each sampler request after completing execution .
for realistic load testing with more user , could you please suggest me which thread group should prefer.
Could you please provide valuable guidance with some valuable link/book and also share me standard performance bench mark criteria or key parameter detail while doing load testing.(if any bench load parameter value does not meet standard then we can say that there is a performance issue)
Thanks for giving valuable time in advance.
Thanks
amit
This is due to the fact that:
Your application response time is too high
Your test duration is too low
For example I can see response times > 80 seconds:
it means that if a single virtual user has cumulative response time for 2 samplers > 160 seconds and the test duration is 120 seconds it will not be able to execute all the requests. Just increase your test duration to be i.e. 10 minutes and you should see more virtual users capable of executing all the Samplers you defined in the test plan.
Also given first user is capable of executing all the requests successfully and in time it looks like that your application gets overloaded hence cannot respond fast enough when the number of concurrent users reaches some "critical threshold", you can add listeners like Active Threads Over Time and Response Times vs Threads, this way you will be able to correlate increasing load with the increasing response time.
If also makes sense to collect:
Baseline health metrics of your application (CPU, RAM, Network, Disk usage, etc.), it can be done using JMeter PerfMon Plugin.
Lower level details like slowest methods, largest objects, heaviest database queries, etc. This form of information can be obtained using profiling tools specific to your application programming language(s).
I'm trying to test my https endpoint with JMeter. I want to make at least 10000 requests per second, but when I set the number of threads to 10000 I get way less rps, around 500.
I've tried setting the number of threads to 1000 and 100, surprisingly I get this same number of rps. I'm using HTTP Sampler and "use Keep-Alive" is set to true. When I look in the statistics I see that when using 100 threads, it makes use of Keep-Alive and connect_time is around 100 ms, but when the number of threads is higher connect_time grows, it's like it stops reusing the connections.
I know this isn't a server issue, because I've tried testing that same endpoint with Yandex.Tank and phantom and it can easily maintain 10 000 requests per second, the problem is it can't use response data to make furhter requests, that's why I have to use JMeter for this task.
This can be done by using "Stepping thread group". It will allow you to send 10000 request per second upto specified time. Refer below image.
Stepping Thread Group
Download jar from below link.
https://jmeter-plugins.org/wiki/SteppingThreadGroup/
I hope you are trying to achieve this using one machine. Try with multiple machine or jmeter distributed mode.
https://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf
https://www.blazemeter.com/blog/how-to-perform-distributed-testing-in-jmeter/
https://blazemeter.com/blog/3-common-issues-when-running-jmeter-scripts-and-how-solve-them/
I am assuming that it is the issue with machine which is not able to generate that much load. Usually, i have use max 300 threads per machine but it depend on the machine config. Just check if the machine is having issue and multiple machine is able to generate more load, considering server is not having any issue.
Hope this helps.
Update:-Usually 200-500 can be handled my modern machines.
Please check the below link to have some more info:-
1.How do threads and number of iterations impact test and what is JMeter’s max. thread limit
2.https://www.blazemeter.com/blog/what%e2%80%99s-the-max-number-of-users-you-can-test-on-jmeter/ .
I am new to jmeter and scripted for login authentication. Project requirement is to see the load for 10K concurrent users.
Script is working fine but to enhance I need suggestions on how to do the following thigs:
How can I see that how much time/average time the server takes to load a page.
which thread grp (studied Ultimate thread group but it is not very clear to me), should be used to see the maximum load the server can sustain in a particular time, for that rampup time need to be adjusted (correct me if I am wrong).
Please tell how to adjust the rampup time with respect to users/waiting time etc., in short how to do incremental/proportional observation to see the server performance(there is no Gateway error etc)
If you're looking for your server capacity boundaries I would rather stick to "requests per second" rather than to "concurrent users" as users may work with different applications in a different way.
For instance, if it is image gallery - the majority of users will be browsing images and do this rather frequently, for instance request next image i.e. each 2 seconds. Given image load time 1 second it will be an image per 3 seconds - 20 images per minute. In this case 10000 users will create the load of 3333 requests per second.
If your site is articles collection, users will need some more time to read an article, i.e. 2 minutes. In that case 10000 users will create 83 requests per second load.
JMeter provides Constant Throughput Timer out of the box, you can set desired target throughput in requests per minute using it. And once you're already aware of JMeter Plugins project, it offers Throughput Shaping Timer - more advanced test element with extended functionality.
If you go "throughput" way, no matter which Thread Group you choose as the load will be orchestrated by aforementioned timers.
See What is the Relationship Between Users and Hits Per Second? article for more detailed explanation.
Once you design your test scenario run it in non-GUI mode (as JMeter's GUI is very resource intensive) as:
jmeter -n -t /path/to/your/testplan.jmx -l /path/to/resultsfile.jtl.
When the test finishes, open JMeter GUI, add Aggregate Report listener and inspect min/max/average response times per requests.