I tried to run Thread group with below details:
Number of thread: 50
Ramp-up period: 120
Duration : 300 s
Loop count: 1 (I create a Loop Controller under Thread Group -infinite loop count box unchecked)
HEAP=-Xms1024m -Xmx1024m
and I set a Constant Timer for (5000ms) as think time after the request
The Problem I have ,is the test has exceeded the duration time....and I don't know when it will finish (the command did not show the prompt)
this is the Jmeter log:
09:15:40,486 INFO o.a.j.t.JMeterThread: Stopping because end time detected by thread: Thread Group 1-46
09:15:40,486 INFO o.a.j.t.JMeterThread: Thread finished: Thread Group 1-46
what did I wrong on this scenario?
is there any idea how to fix it....(Link for screenshot):
https://imgur.com/a/We3PfO9
Your Loop Controller does nothing, it controls how many times its children will be executed and since it doesn't have any children it doesn't make any sense.
Your 2 log lines are not very informative, if you want to know for sure where JMeter is stuck you need to take a thread dump and see what exactly the threads are doing. A "blind shot": at least one of your HTTP Request samplers fails to get response in 5 minutes as the application doesn't respond or there is another transport-layer problem. Consider setting reasonable connect and response timeouts at the "Advanced" tab of the HTTP Request sampler (or even better use HTTP Request Defaults)
Your heap size might be too low, consider monitoring heap space usage and garbage collector activity using i.e. JVisualVM
Make sure to follow JMeter Best Practices
Related
I tried to test how many limits of VUs that my pc can handle. So far i tried to run with 5000 VUs with GUI mode, its working fine so wondering if this is really the correct way to do it. Here's my laptop specification:
16GB DDR4, 512GB SSD, i5 7th gen
For now I already test with 6 HTTP requests, thread group information as below:
Can anyone verify whether im doing correct way to test the limit? And why does when the test is running, the number of user run at top right is still 47? But at the end of the test, it really shows that it ends with 5000 VUs in the summary report listener (Please refer Jmeter logs in the first screenshot)
You have only 1 loop and 120 seconds ramp-up in the Thread Group so JMeter starts 41 users each second. Once started user starts executing Samplers upside down and when the last sampler is done the thread is being shut down.
So you're running into the situation when some threads have already finished their job and ended and some haven't been yet started. If you want to reach 5000 users then you need to tick Infinite next to Loop Count and specify Thread Lifetime to be greater than your ramp-up time.
More information: JMeter Test Results: Why the Actual Users Number is Lower than Expected
According to JMeter Best Practices you should:
Run your test in command-line non-GUI mode
Disable or delete all the Listeners as they don't add any value, just consume the resources
Once your non-GUI test execution is finished you can either open the .jtl results file using a Listener of your choice or generate HTML Reporting Dashboard out of it and analyze the results
I configured Java based Selenium WebDriver test in Apache JMeter with the following setup:
Number of Threads (Users): 10
Ramp-up period (Second): 120
Loop Count: 1
I ticked the Delay Thread Creation until needed to save resources.
My expectation regarding the functionality:
I expected that if I have 10 users with 120 seconds ramp up time, then every user activity will start each other and the Jmeter will wait at least 12 seconds to start the next thread.
The issue is:
The threads start sometimes within 11 seconds, sometimes 12 seconds.
I don't know why does it happen because I would like to see the threads start after each other exactly in 12 seconds.
The question is
Are there any solution that to tell the JMeter to wait exactly 12 seconds for next thread start?
Here is the picture about started jobs with date time stamp:
I don't think you will be able to achieve this level of precision using ramp-up period approach of the normal Thread Group, a better idea would be going for the Ultimate Thread Group (can be installed using JMeter Plugins Manager) which allows absolute flexibility in terms of definition of ramp-up, ramp-down and time to hold the load.
Example setup:
Example output:
In order to get only one execution of the "job" per each virtual user you can use Throughput Controller configured like:
You can add Flow Control Action for pausing exact time
it allows pauses to be included without needing to generate a sample. For variable delays, set the pause time to zero, and add a Timer as a child.
I'm using JMeter 3.1.1 to run a load test. My test plan is with 40 threads and each thread executes 6 HTTP Requests. It is running fine for the first few hours with a latency of around 20ms.
After few hours, latency grows up to 500ms. I verified that server is processing fine. Also, I have no 'Listeners' in my test plan and I run it in NonUI mode.
Also it seems that the thread group is executing only one thread at time. Coz I see hardly one or two requests being executed by thread group per second.
Im really clueless what to suspect. Any help would be greatly appreciated.
BTW., memory and CPU consumption are normal.
About my TestPlan:
Total Thread Groups:4
1. Setup Thread Group
2. Load test thread group with 40 threads
(Action To be taken after error :Continue
Ramp-Up period: 0
Number of Threads: 40
Loop Count: Forever)
2.1 Counter
2.2 Random Variable
2.3 User Defined Variables
2.4 If Condition = true
- 2.4.1 HTTP Request1
- 2.4.2 HTTP Request2
- 2.4.2 Loop for 5 times
-- 2.4.2.1 HTTP Request1
-- 2.4.2.2 HTTP Request2
3. Introspection thread group with 1 thread
4. Tear Down thread group
Please let me know, if more details are needed
Another observation is:
Server is having TIME_WAITs : 4418 (I check 'Use keep-alive' option for HTTP Request., still so many TIME_WAITs)
Latest Observations(Thanks to one and all for your valuable comments)
Actually, the memory must be an issue., I have given already like this.,
-Xms512m -Xmx2048m -XX:NewSize=512m -XX:MaxNewSize=2048m
But I really wonder why JVM was not going 512 MB. So i tried with both Xms ans Xmx with 2g each. Now its kind of running for more longer. However it' performance is slowing down still. May be my Beanshell Post Processors are consuming all the memory. I really wonder why they are not releasing the memory. If you see., per hour how the performance is degraded.
Hour #Requests sent
---- --------------
Hour 1: 1471917
Hour 2: 1084182 (Seems all 2g heap is used up by this time)
Hour 3: 705471
Hour 4: 442912
Hour 5: 255826
Hour 6: 136292
I read that Beanshell hogs memory, but I have no choice but to use it as I have to use a third party jar with in the sampler to make few java calls. I'm not sure if I can do the same using JSR223(Groovy) or any other better performing sampler (pre / post processor)
as you have seen the Heap settings I did., here are the Memory and CPU Utilization of Jmeter. Im running 100 threads now. What should I do in my test plan to reduce the CPU utilization. I have a 100ms sleep after every 4 HTTP Requests.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11850 xxx 20 0 7776m 2.1g 4744 S 678.2 27.4 6421:50 java
%CPU: 678.2 (Fluctuating between 99% - 700%)
MEM: 2.1g (Xmx = 2g)
1) Do you run the JMeter with standard script (jmeter/jmeter.bat)?
Then mind that the default size for JVM heap in there is capped at 512M. Consider increasing it, at least at the maximum end (means, change default -Xmx512m).
Next thing to consider is the -XX:NewSize=128m -XX:MaxNewSize=128m default values.
Here's what Oracle suggesting:
In heavy throughput environments, you should consider using this
option to increase the size of the JVM young generation. By default,
the young generation is quite small, and high throughput scenarios can
result in a large amount of generated garbage. This garbage
collection, in turn, causes the JVM to inadvertently promote
short-lived objects into the old generation.
So try to play with this parameters, that may help.
P.S. Aren't you, by chance, running it at AWS EC2 instance? If yes - what's the instance type?
Thanks to all, who all tried to help me.
However., I could resolve this.,
Culprit is : If Controller, which is evaluating the condition for every iteration of every thread. Sounds quite normal isn't it? The problem is., condition is evaluation is JavaScript based. So all threads are eating CPU and Memory for invoking JavaScript.
Now Im getting consistent requests to server and JMeter is also almost stable at 1.9g of memory for 100 threads.
Im posting this just in case any one can get benefited without wasting day and nights figuring out the issue :)
I am new in Jmeter , I am familiar with LR. But not able to get some functionalities in jmeter for "VUser/Thread Group ".
While I am running my script with 10 threads in jmeter , what does that mean () :-
all 10 users are performing same action at same time
or
each thread is performing separate actions
or
once one thread complete then another thread will start its execution.
How to put 'Rendezvous' function in jmeter for some particular transaction or action like we used write lr_rendezvous("R1"); in Loadrunner to hit all vusers at same time. Is that possible in Jmeter then how ?
If you set number of thread as 10 its loadrunner equalent as executing with 10 virtual users. all threads will start executing at same time.
You can use Synchronizing_Timer for achieving Rendezvous in JMeter
http://jmeter.apache.org/usermanual/component_reference.html#Synchronizing_Timer
https://blazemeter.com/blog/using-jmeter-synchronizing-timer
Concerning the 1st part,
'running script with 10 threads' means that they would all start running at the same time... IF ramp-up time == 0.
If you set ramp-up to [someValue] - the threads will get asynced. See the article from jmeter docs.
Each thread will execute the test plan in its entirety and completely independently of other test threads. Multiple threads are used to simulate concurrent connections to your server application.
The ramp-up period tells JMeter how long to take to "ramp-up" to the
full number of threads chosen. If 10 threads are used, and the ramp-up
period is 100 seconds, then JMeter will take 100 seconds to get all 10
threads up and running. Each thread will start 10 (100/10) seconds
after the previous thread was begun. If there are 30 threads and a
ramp-up period of 120 seconds, then each successive thread will be
delayed by 4 seconds.
If you are reproducing human behavior a full rendezvous event, more than one person in the same section of code at the same time engaging in the same function, is exceedingly rare....on the order of a credit card company having only 4-5 people in such an incident on the largest shopping day of the year.
So, if you are headed down this path, consider if you are trying to reproduce human behavior or if you have a technical metric you are hitting with a small number of focused users on such an event.
The use of exceptionally highlighted rendezvous use on a resume is a mark of someone you do not want to hire.
my problem is quite complex.
The matter is to test our web site answers to an increasing amount of requests from different users.
So I can take users/passwords from a CSV Data and launch an HTTP request (with variables readen from the file).
But I don't want to run the thread with all users at same time, but to loop and add at every iteration an other user from the file to the running thread groups (after some delay).
It seems very difficult to do so with jMeter. Perhaps I's need to call a custom java class ?
If I understand you correctly, you just should use Rump up. This parameter control how fast your test will reach maximum threads count.
As explained in JMeter documentation,
The ramp-up period tells JMeter how long to take to "ramp-up" to the
full number of threads chosen. If 10 threads are used, and the ramp-up
period is 100 seconds, then JMeter will take 100 seconds to get all 10
threads up and running. Each thread will start 10 (100/10) seconds
after the previous thread was begun. If there are 30 threads and a
ramp-up period of 120 seconds, then each successive thread will be
delayed by 4 seconds.
Also may be this Throughput Shaping Timer may be helpful for you. You can schedule duration of request with it.
As Jay stated, you can use ramp up to try to control this, though I am not sure the result will be what you are after...though it will add the startup delay. If you have a single thread then each row of the CSV will be processed one at a time, in order.
You can set the thread group to 1 thread and loop forever. In the CSV config you can set a single pass and to terminate the thread on EOF.
CSV Data Set Config-->Recycle on EOF = False
CSV Data Set Config-->Stop thread on EOF = True
Thread Group-->Loop Count = Forever
Also keep in mind that by using BSF and Beanshell you can exact a great deal of control over JMeter.
You should check out UltimateThreadGroup from jmeter-plugins.