New answers tagged

0

Although Constant Throughput Timer accepts value in Requests/min and you are saying that you will use 120/sec, so you will have to provide a value of 7200 in Constant Throughput Timer to achieve 120/sec. Assuming there is only one request (sampler) in your Thread group and you are using the setting "All Active Threads" in Constant Throughput Timer. Then by ...


2

Answer is 1500. During hold time only 1500 requests will be kept alive. It depends on many factors and one of the factor is whether you used "Cookie Manager" in your scripts. If "Clear cookie each iteration" checkbox is checked then every session or cookies will be cleared after each iteration. So At the hold time only 1500 requests will be alive ...


0

Constant Throughput Timer can only pause the threads to reach specified "Target Throughput" value so make sure you provide enough virtual users (threads) to generate desired "requests per minute" value. See How to use JMeter's Throughput Constant Timer guide for more information.


0

As far as I know, it doesn't matter which type of Thread group you are using with Constant Throughput timer, at the end of the test in the results, you will get your desired Throughput which you mentioned in Constant Throughput Timer i.e. if you have mentioned 1200/min in Constant Throughput Timer with "Calculate Throughput based on" value as "All active ...


1

That depends on how your system defines a login session. Typically it is the server, not the client, that decides when a login session is over. You need to figure out (or ask a developer to describe) the session lifecycle for your system.


1

If you have 100 Threads in thread group and Ramp up time as 20, these 100 threads aren't concurrent. To maintain concurrency for 100 threads you have to use either loop counts or Durations (Scheduler in Thread Group). You may try with the "Ultimate Thread Group" (JMeter plugins) instead of only "Thread group". To check this, you can use "Active Threads Over ...


2

It depends. JMeter acts as follows: JMeter starts defined number of threads during ramp-up period Threads start executing samplers upside down (or according to Logic Controllers) When thread doesn't have any more samplers to execute or loops to iterate - it's being shut down So if your test is short enough you may easily run into a situation when 1st ...


1

set ramp up time to zero to start all the thread at same time. difference in starting time between threads = Ramp up time/ no of threads. If you have ramp up time = 20 and no of threads = 100 then each thread with start with time gap of 0.2 (20/100) sec from previous thread


0

As per your configuration, each thread(user) will start their action after 20/100 =0.2 seconds. i.e. after first thread has initiated, second thread will start after 0.2 seconds. If you want to verify the same from Jmeter, on the top right corner threads are shown once you start the action.


0

This might be because some of application requests are taking too long to execute, holding the application server’s threads busy, and not allowing the resources to be used by incoming requests. Try the running the test with 4000 concurrent users, then 6000 users and so on. Check at number of request you are getting this error.You must verify Apache ...


2

This is a network constraint over which you may not have any control. Do you know after what time you get this error? You could play with Timeouts section on HTTP Request Sample and keep it higher than the time which causes timeout error.


0

JMeter provides a way to perform distributed testing. This comes in the form of a master-slave setup. In this mode, there is a machine known as a master, which controls a number of client machines (JMeter instances) known as slaves. This approach has some benefits, including managing multiple JMeter instances remotely from the master node, automatically ...


2

I don't know why you need to run multiple instances of Jmeter from single machine. But Yes, you can run multiple instances of JMeter from single machine without any major issue, the only limitation will be with the memory used by JMeter as if you ran too many instances or few instances using too much memory then you may ran out of memory and JMeter execution ...


1

Your requirements could not be fulfilled just by setting users and iterations. Here's why. By default, users act asynchronously. So when user 1 completes iteration 1 it will proceed with iteration 2 without waiting for other users to complete iteration 1. It looks like you specifically require for a user not to start the next iteration until all other users ...


1

Assuming your question requires the following: 200 Virtual users. Each runs the same test case. Data driving is used, with 100 sets of data. Each user shall run one test case then pause until the next round starts. There will be five rounds. Thus a total of 5*200 = 1000 test cases should be executed. There is no built in facility for this load pattern. ...


2

As the iteration count is 1 only one test case is executed. Both the scenario and the run settings provide an iteration count. Both relate to number of test cases executed. See this Microsoft blog for some more information. Set the iteration count in the scenario to 0 (ie zero) to let the values in the run settings control the number of tests executed. ...



Top 50 recent answers are included