I had used JMeter for load testing but was stuck at a point where had to execute parallel requests which does not seem possible with it.(if possible kindly explain)
So is there any open source tool which could help. Have to increase load upto at least 1000VU
Depending you your hardware you may need to consider remote (distributed) testing where one master host orchestrates multiple JMeter slaves to create immense load.
In regards to "concurrency" JMeter offers 2 test elements to control load pattern.
Synchronizing Timer - for firing X requests at the same moment of time
Constant Throughput Timer - to set exact load like X requests per second
which does not seem possible with it.(if possible kindly explain)
Increase the number of threads(users), that would be the number of simultaneous requests. The home page shows the exact example:
http://jmeter.apache.org/usermanual/build-web-test-plan.html
Hope this helps.
Feel free to try Yandex.Tank - https://github.com/yandex-load/yandex-tank. It can make to 80k parallel requests per second.
As Mr. Dmitri said, You can consider the distributed testing using jmeter.
Also consider the following points,
1.Use 64 bit JVM and increse the heap memory.
2.Run load testing in non gui mode and remove all listeners (you can add it after testing to display results)
3.Use latest version of Jmeter(2.11), because of optimal resource utilization (CPU,Memory). OR
Use Gatling load testing tool(http://gatling-tool.org/). You can find an comparative study of gatling Vs Jmeter
Related
How to create proper workload model in JMeter if I have only number of concurrent users and response time as input/requirement? Do I need any additional information in order to load test app?
If these are only info I can get, how to approach load testing in context of using JMeter as load testing tool, any ideas - suggestions - advices?
A "proper workload" would be simulating real life usage of the system under test by "the number of concurrent users".
Just replicate real user behaviour at HTTP protocol level paying attention to pretty much everything i.e.
JMeter's network footprint must be exact replica of the browser's network footprint when it comes to HTTP requests so cross-check the number and the nature of the requests from browser developer tools and JMeter's View Results Tree listener
Make sure to send the same/proper HTTP Headers
As a subset of point 2 pay attention to Cookies
Make sure to download embedded resources like browser does
In addition to point 4 make sure to properly handle cache
Use Timers wisely to simulate think times
If your users are doing different actions configure your JMeter test to distribute them like real users are distributed
Once done just run your test with the anticipated amount of users for the desired duration and compare the real response time against the anticipated
The Avg RT and other KPIs (such as Throughput) are the result of generating or executing the workload with a determined # of VUsers. IMO, the best approach is to generate the load by varying the VUsers as shown in the graph:
This graph also shows a key concept: perfomance (as measure by KPIs) is not linear (although it might appear linear at a small # of VUsers).
Can someone guide how can I achieve below scenarios via JMeter
1.Check if system is able to process 1,00,000 random searches per hour
2.Check if system can accept 1,00,000 transaction's per minute- this is more like form submissions
First of all you need to implement your test scenarios (search and submitting forms) using HTTP Request samplers
The HTTP Request samplers can be:
Recorded using JMeter's HTTP(S) Test Script Recorder
Recorded using JMeter Chrome Extension
Created manually basing on your application/endpoint specifications
Once you have test project skeleton and perform necessary correlation of dynamic values and parameterization of dynamic parameters like usernames you can start defining the workload, i.e. see Building a Web Test Plan user manual chapter
Add as many virtual users as needed, run your test and see whether your application can handle the anticipated load.
Suggested scenario:
Increase the load gradually, i.e. start with 1 user and increment the number of users till the projected amount
Look at Transactions per Second chart and Active Threads Over Time chart. On well-behaved system the throughput (number of requests per second) should increase as the number of users increase.
If you detect the point when you increase the load but the throughput doesn't increase - it means that the system reached the maximum performance. If it is sufficient - you can report the test as passed, otherwise you will need to investigate the root cause and either report or fix it if you're capable of doing this.
I am testing asp.net website using Jmeter. I have used below scenarios to load test. Scenario 1 give me correct result(What I expect and can be wrong) and Scenario 2 is not giving same result. But I have used same number of requests within same time. Can someone explain me why is this?
Scenario 1.
Scenario 2.
Ramp up time does not determine when any of your tests are going to complete. It only controls when your test is going to start.
Also, the number of threads any test can create concurrently is limited to the memory you've allocated to JMeter. Even though you've set the thread count to 60000, if you've hit the maximum memory you've allocated, the threads will either queue up or never generate (you can watch the JMeter logs for thread creating or errors).
I recommend tuning your JMeter instance so you have some stability to your tests, here's a good guide. LINK
No of requests you have sent might be same. But the concurrent user load on the server is completely different.
I had clarified similar question few weeks ago. You can check the answer here.
Check Here
If suppose I will run load testing with 5000 threads or may be more ,
Will the main server under test crash at a certain level.
As EJP said, it is JMeter purpose to find the limit of tested application and how it will react under performance.
So yes it is perfectly possible.
You should read JMeter Manual.
If you are doing any kind of performance tests (load, stress, soak etc) you will want to know at what point your application server falls over i.e. its breaking point.
Once you've found out what your upper limit is, start dialing back the number of threads until you find your application's "sweet spot" for example CPU usage <80% & >70%
I want to load test a URL by hitting it few hundred times at same millisecond . I tried JMeter but I could hit 2 request at same millisecond. This seems to be problem that my machine cant create threads fast enough . Is there any solution to the issue ?
In JMeter you can use synchronizing timer setting it to 100, this way all threads will wait until there are 100 available and hit the server:
http://jmeter.apache.org/usermanual/component_reference.html#Synchronizing_Timer
Another solution is to increase the number of Threads so that you hit this throughput.
In next coming version (2.8) of JMeter you will be able to create threads on demand (created once needed).
Anyway hitting few hundred times at same millisecond is a high load so you will have to tune JMeter correctly.
Regards
Philippe
JMeter uses blocking HTTP client, in order to hit the server at the exact same time with 100 reqeusts you need 100 threads in JMeter. Even providing that, you still don't have 100 cores to actually run such code at the same time. Even if you had 100 cores, it takes some time to start a thread, so you would have to start them in advance and synchronize on some sort of barrier. And that is not supported in JMeter.
Why do you really want to run your server "at same millisecond"? An ordinary load test just calls the server with as many connections as possible, but not necessarily at the same time. Moreover, sometimes you are even adding random sleep between requests to simulate so-called think time.
As per Philippe's answer, JMeter does in fact support synchronous requests. But maybe for what you want something like Apache Bench using -c100 (or tune it to whatever works) is a better option? It's pretty basic stuff but then the overhead is a lot smaller which might help in this situation.
But I would also steal from Tomasz's answer and echo his concern that perhaps this is not really the best way to approach load testing. If you're trying to replicate real life traffic then do you really need such a high level of concurrency?
You need to use Jmeter-server and a host of client machines for load generation. Your single machine is not enough to generate the load itself.