Jmeter Ultimate thread group - Populating the user details from a csv - jmeter

I am trying to replay production logs where the User count varies every second. Currently, I am using Jmeter - Ultimate thread group where we can definethe user scenario. Is there a way, we can populate the user details(Number of Users, Initial delay, etc) from a csv file into the ultimate thread group (I may need to fill in for abt an hour).
Thanks,
Praveen

Maybe it's possible by adding a "CSV Data Set Config" to your thread group - although I'm not sure how to loop through the csv values in one table.
But the easier way (as hinted at in the Ultimate Thread Group docs) is to add threads_schedule to your user.properties file. Just add to the last line
threads_schedule=\
spawn(15,1s,1s,1s,1s) \
spawn(40,1s,3s,1s,2s)
You could use a special file you load on jMeter startup, using a -q UTG.properties commandline argument. The backslashes escape the newlines, so it's almost like csv - you could export a csv from excel and do a pretty simple find and replace to add spawn( and )\ to the beginning and end of each line.

Related

Can we parameterize Thread schedule details like Start Thread count, Initial delay etc. in Ultimate thread Group using csv/txt files?

We are trying to parameterize Thread schedule details like Start Thread count, Initial delay etc.
Since we have 50+ thread groups and handling them has become an issue.
Would like to know if Jmeter has any unknown feature for this or a workaround to achieve this?
Can we parameterize these values from a csv/txt file?\
Note: We have 50+ thread groups, hence using ${__CSVRead} and retrieve different values didn't work out.
Have tried out ${__CSVRead} but since we need different values for each thread, this isn't working out.
I can only think of "known" feature - using either user.properties file or a custom .properties file, i.e.
thread.group.1.start.threads=10
thread.group.1.initial.delay=5
thread.group.2.start.threads=50
thread.group.1.initial.delay=20
etc.
and you will be able to use __P() function in the Ultimate Thread Group to read the values from the .properties file:
If you put the values into user.properties file - you won't need to do anything else, the file will be picked up automatically, if you decide going for the custom .properties file - you will need to pass it via -q command-line argument:
jmeter -q /path/to/your/thread/group.properties -n t .....
More information:
Configuring JMeter
Apache JMeter Properties Customization Guide
Full list of command-line options

Reuse parameters from single CSV Dataset for multiple users

I am using "CSV Dataset config" to read a parameter from the specified CSV file. I have set the "Sharing Mode" as all threads. For that Thread Group, I have specified "Number of Threads" as four (for four users). I have set "Recycle on EOF" as "True" (I tried with "False" too, but no difference).
When I start the test, It ran for just one user, read all the data from the CSV file, completed the test and stopped. For the other three users, it did not run at all. My guess is - because the CSV file was closed once the testing for user 1 completed.
I tried using multiple Thread Groups in the same Test Plan and each Test Group had just one user. Even then it did not work.
The expectation is- the same CSV file can be used for multiple users and across different Test Groups. There must be a way to rewind the CSV file either by JSR223 Post Processor or otherwise.
I cannot reproduce your issue using JMeter 5.2 and it is quite hard to tell anything comprehensive without seeing your Test Plan.
My expectation is that you violated JMeter Scoping Rules somewhere somehow, i.e. you placed CSV Data Set Config inside one Thread Group while it should live at the same level as all Thread Groups
Given
The following CSV file stored as test.csv in JMeter's "bin" folder:
line1
line2
line3
And the following CSV Data Set Config:
2 Thread Groups set up like:
You should see that each virtual user in each Thread Group is reading next line from CSV file on each iteration:

JMeter tests in Non-GUI mode are not trustworthy

The test scripts on GUI works perfect but not in the non-GUI mode.Image showing Terminal test execution
Explanation:
I have 3 thread groups in the test plan, where the first Thread Group creates 3 .csv files and are expected to feed the data in the CSV files into the second Thread Group.
For few test runs, Non-GUI mode worked great but then, the tests Intermittently like this [Terminal showing test run], doesn't create the CSV files at all and also,
sometimes, third Thread Group doesn't execute at all.
The problem I noticed is:
During the NOn-GUI tests the files are not been creating, so that's the reason the next Thread groups weren't able to pick up and use the variables inside CSV file and also
The second One could be: I'm saving folder and file paths in the
${__setProperty(prop_folder_Path,${File_Path})} and getting the prop.
${__property(prop_folder_Path)} in another Thread Group -> Sometimes this property function Doesn't work and files are saving in /bin Directory
Is there a way to use ${__property(prop_folder_Path)} value in BeanShell POStProcessor ?
I believe whatever works in the GUI should work same in the Non-GUI too, AM I right?
I Just noticed that output files are creating in /bin folderas shown here while running the tests in NOn-GUI
Any suggestions to fix this. Thank you
My expectation is that your ".csv" files creation fails somewhere somehow therefore 2nd thread group is not able to operate due to missing files.
JMeter doesn't have any build-in functionality to write something into the file so I think you implemented some custom logic using i.e. JSR223 Scripting which doesn't work. The reasons could be in:
If you're running JMeter from another folder the .csv files can be created in a different location, try using full paths just in case.
Non-GUI mode tends to be faster than GUI mode so it might be the case of multithreading issue i.e. when multiple threads are trying to write data into the same file concurrently and clash or produce not well-formed data.
In both cases the answer will live in jmeter.log file, check it for any suspicious entries and fix the causes.
In general using files to pass data between thread groups is not the best idea, I would recommend doing it in-memory instead, for example:
In 1st Thread Group use __setProperty() function to convert your data which you store in CSV file into JMeter Properties like:
${__setProperty(foo,bar,)}
In 2nd Thread Group use __P() function to read the data like:
${__P(foo,)}
More information: Knit One Pearl Two: How to Use Variables in Different Thread Groups

Jmeter wont read csv file with line feed properly

I have a thread which writes data to a csv file and data looks like this in that file, as you see below each data is separated by a , then line feed.
ApiKey
20a145260241463194bf84f43952da9c:dut8ghdt+iQrsmYEgKzHzF1It79aWRIjb/d1wM8U3WE=,
93,
d0e29bb7-476d-4a52-9527-e5d9bb0ac34a
In another thread I am trying to read the data so I have done the following. Added a "CSV Data Set Config" with correct filename variables X,Y,Z and my Delimiter I have tried all these A=,n or B=n or C=n, I am not able to get Y and Z properly. What am I doing wrong?
Synchronization of data between thread groups using CSV files is not the best idea as you will have to implement a form or read/write lock to ensure that only one thread is writing data to the CSV file at a time and that will cause throughput degradation.
So I would recommend going for one of the following solutions:
Use __setProperty() function to convert the data from JMeter Variables into JMeter Properties. JMeter Properties are global for the whole JVM therefore they can be accessed from another Thread Group(s). See Knit One Pearl Two: How to Use Variables in Different Thread Groups article for more information.
Use Inter-Thread Communication plugin which implements FIFO queue so you can block threads in 2nd thread group unless data from 1st thread group is available. You can install Inter-Thread Communication Plugin using JMeter Plugins Manager
Both approaches are in-memory therefore you will not need to store data in interim files.

Proper way to save Jmeter Results to csv - how to finalize results file

I do the same scenario that was already described in other topics not at once: I'm trying to save Jmeter results to database from csv file.
I have an Aggregate Report listener that saves results to csv file, and everything is OK here.
I also added TearDown Thread Group to my scenario that gets strings from this csv file (by CSV DataSet config) and processes it to database. This part also works fine with static CSV.
Two problems here:
Aggregate Report listener is added on the top level of scenario. So, it adds all samplers from TearDown group to results file as well. So, it's like a recursion: if I do teardown until end of result file, I'll never reach the end, as every new iteration adds some new rows.
At the moment when CSV dataset config takes csv file, it's still in memory only and not finalized to disk. So, file is just empty. How to tell Jmeter that it should write the content from memory to a file and close input stream?
Any ideas how to solve it?
I know that I can move Listener into threads, but in this case I have to duplicate it for every thread group. It's always better to have one listener in one place as I can potentially change its settings.
Thanks in advance.
There is a JMeter Property jmeter.save.saveservice.autoflush defaulting to false
# AutoFlush on each line written in XML or CSV output
# Setting this to true will result in less test results data loss in case of Crash
# but with impact on performances, particularly for intensive tests (low or no pauses)
# Since JMeter 2.10, this is false by default
#jmeter.save.saveservice.autoflush=false
You can amend its value by setting it to true so JMeter will write down each single line of results into the file and closing the file once done. It can be done in 2 ways:
Permanent: add the following line to user.properties file (located in JMeter's "bin" folder)
jmeter.save.saveservice.autoflush=true
You will need to restart JMeter to pick the change up
Ad-hoc: pass the property via -J command-line argument
jmeter -Jjmeter.save.saveservice.autoflush=true -n -t .....

Resources