I have 10 concurrent users, and for 2 concurrent users, I need to assign x bandwidth, for 6 users I need to assign y bandwidth and for remaining 2 I need to assign z bandwidth.
How do I achieve the above scenario?
Can I achieve this by using stepping thread group and how?
if we cannot achieve this by using stepping thread group how will I achieve this?
You can't achieve this by using Stepping TG. JMeter lets you simulate network bandwidth very easily but it is not possible in Thread level.
JMeter does give you the option to throttle outgoing bandwidth in order to simulate different network speeds. The bandwidth can be controlled through these two properties:
httpclient.socket.http.cps=0
httpclient.socket.https.cps=0
These are for the HTTP and HTTPS protocols respectively.
Configuration prerequisite:
Ensure you use HttpClient 3.1 or HttpClient 4 implementations.
Configure bandwidth by defining the 2 properties above in <jmeter home>/bin/user.properties.
You will find these properties in <jmeter home>/bin/jmeter.properties location.
The acronym “cps” stands for "characters per second".
cps values are calculated with this formula :
cps = (target bandwidth in kbps * 1024) / 8.
For some popular bandwidth presets and more detail you will find these two blogs Controlling Bandwidth in JMeter and How to Simulate Different Network Speeds in Your JMeter Load Test really helpful.
If you run your test in the distributed mode you can set a different bandwidth for each remote engine by specifying your desired “cps” value in the user.properties file.
Related
I have to achieve tps of around 2000 in jmeter but able to get around 1000 tried following things -
-Increasing the config
-Distributed Load Testing
-Increasing heap memory
-Increasing or keeping the threads as per the standard formula(followed jmeter best practices)
is there any other way I can do this?
Normally in order to get more throughput you need to add more threads (virtual users) in the Thread Group
If you cannot add more threads due to lack of resources (CPU, RAM, etc.) - consider switching to Distributed Testing
Of course the system under test must be able to respond fast enough because if the application you're testing isn't capable of serving more than 1000 requests per second - you won't be able to get more unless you identify and fix the bottleneck
I am currently using JMeter command line to trigger load test under master(2GB Memory & 1 Core) and slave machine(2GB Memory & 1 Core)
How many threads are supported by JMeter for above configuration.
Do we need to change any thing in Heapsize to get maximum threads?
Can any one help in this regard.
We don't know, it might be the case even 1 thread is not supported, it might be the case 2147483647 users are supported.
The number of virtual users you can simulate varies and depends on different factors like:
The nature of the test (what protocols are in scope, what exactly the test is doing, etc.) For simple GET request with small response you will be able to simulate more users, for complex POST request with a lot of calculated encrypted parameters uploading several large files the number of users will be much less
The size of request and response
The number of pre/post processors, assertions, etc.
So the only way of telling how many users you can simulate to measure it
Make sure to have monitoring of essential OS health metrics like CPU, RAM, etc. usage is in place. If you don't have any solutions in mind you can consider using JMeter PerfMon Plugin
Make sure to follow JMeter Best Practices
Start with 1 user and gradually increase the load at the same time looking at the CPU, RAM, Network, disk usage, etc.
When any of monitored metrics starts exceeding, say, 80% of maximum available capacity take a look at how many threads are online just before this moment using i.e. Active Threads Over Time listener
This is how many users you can simulate for particular this test on particular this hardware/software combination
I want to understand the actual JMeter throughput behavior achieved at runtime.
Scenario - I'm increasing the JMeter throughput at runtime using Constant Throughput Timer and beanshell script as described here - https://www.blazemeter.com/blog/how-to-change-jmeters-load-during-runtime.
Test plan - Along with CTT as described above, simple threadgroup with fixed #threads and infinite loop iterations is configured. HTTP Sampler for GET call is used. No other timer or plugin is added in the test plan.
As I keep on increasing the target throughput of JMeter at runtime, I noted that the actual achieved throughput value is limited by mainly 2 factors -
The threads in my thread group.
The performance bottleneck of target app.
I have questions regarding both the limitations -
Once the highest throughput is achieved using all threads in current threadgroup (assuming there're no errors from the target app yet), is there a way to increase the #threads at this point dynamically at runtime to achieve a higher JMeter throughput?
Now as I keep on increasing JMeter throughput, it can't be increased further due to errors from the target app. How does the JMeter identify performance bottleneck of my target app and react to it? Does it add any delay or kill threads or apply any such mechanism to reduce it's throughput to the max that the target app can sustain?
In continuation with point #2, if JMeter identifies and reacts to the performance bottleneck by any method, what are the factors (like error rate, response latency etc.) that control it's throughput to keep it within the max limit of the target app? Are these factors configurable or extensible?
You can play the same trick with the number of threads in the thread group, just define it using __P() function and you will be able to manipulate it using Beanshell server. Another option is using a JSR223 Test Element and Groovy language to add the new thread(s) where/when required like:
ctx.getThreadGroup().addNewThread(0, ctx.getEngine())
JMeter doesn't "identify" anything, it just tries to execute Samplers as fast as it can and the number of requests per second depends on 2 factors:
your application needs to be able to respond fast enough
JMeter itself needs to be able to send requests fast enough, i.e. you need to follow JMeter Best Practices
there are no "mechanisms" which detect the application under test behaviour, the closest solution is Auto Stop Listener
See point 2
I have a business requirement wherein I want to simulate bandwidth related load tests targeting different bandwidth and in a steady manner.Like we have ultimate thread group in JMeter to control the users providing a steady ramp up at given time. Do we have any such element/plugin to control enormous bandwidth like 70 Gigabit/sec in JMeter or BlazeMeter?
"Bandwidth" is basically the sum of sent and received bytes so it mostly depends on request and response time.
If you have 1 megabyte request/response - in order to simulate 70 gigabit you will need to send 8750 requests at the same moment.
So I would recommend executing your test plan with 1 virtual user and 1 iteration and look into last 2 columns of the Aggregate Report listener
This is how many (kilo/mega/giga)bytes your test produces for the test duration. Divide it by test duration in seconds to find out the bandwidth "per second" and divide 70 gigabits by that number to find out how many requests you will need to make.
Most probably you will need to go for distributed testing (unless you have a single machine with 100-gigabit network adapter capable of running required amount of virtual users)
I want to use above 5000 thread in Jmeter, SO what should be the system configuration. Now Am using 4GB RAM , 2.3 GHZ, Now it shows only 3000 threads results only in Summary Report.
In jmeter have any maximum number of limitation?
There is no limitation except:
Your machine CPU power
Your memory and JVM size
Your network interfaces
Answer depends on a lot of factor, You should read:
What is the highest number of threads that is reasonable to simultaneously run in Jmeter? (The accepted answer is not correct anymore)
JMeter max. thread limit
So you will have to benchmark your machine with your plan and see to where you can go, then different options:
1 machine is ok, that's it
You need more, switch to distributed testing or use a Cloud solution