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
Related
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
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 .....
I have been using the following BeanShell script in order to delete all output files before each new run of a test plan
import org.apache.commons.io.FileUtils;
FileUtils.cleanDirectory(new File(vars.get("OutPutFolder")));
My test plan consists of a Thread group that is using 100 users (number of threads) with a loop count of 5.
I have tried several ways to incorporate the aforementioned beanshell script but i cannot seem to find the right place to put it in.
Things that i have already tried:
Creating a new "setup thread group" ("Run thread groups consecutively" is checked)
and place script in a beanshell samples > Files do get deleted but outcome files are not persisted to the disk (re-deleted by my script)
and place script in a beanchsell PreProcessor > Files do not get deleted
Placing script in my main Thread group > Files do get deleted but outcome files are not persisted to the disk (re-deleted by my script)
Using an If Controller (${__BeanShell(vars.getIteration() == 1)} && ${__threadNum} == 1)
Not solving your problem, but based on your comment, here's a different simple solution, which provides you with ability to separate current test results from previous test results.
All the listeners in JMeter can accept a dynamic file path, and one of the dynamic values they can use is TESTSTART.MS property (see here), which will be different for each test execution.
So in order to make name of each output file (or report) unique for the run you can use that property in the name of the output file:
your/path/${TESTSTART.MS}_errors.csv
You can even create a sub-folder holding set of the output files for specific execution, like this:
your/path/${TESTSTART.MS}/name1.ext
your/path/${TESTSTART.MS}/name2.ext
That way the names never collide, and they are grouped by execution (all files from the same execution will have the same timestamp, so you can filter them).
On top of that, on linux you could use logrotate to zip old jmeter logs (and since they are just text files, they zip nicely)
I have a jMeter project I'm working on which has thrown up all sorts of problems. Mainly due to storing and scoping of variable data throughout the run.
I now have things pretty much working and I'm using a Beanshell shared hashmap to store data through the run. I don't need to worry about thread safety due to the way I'm doing it.
It works, but it re-initialises itself each time a thread group runs. Despite putting the initialisation step outside all thread groups.
So, as I understand it, the solution is to put all the startup data into an initialisation file which is only run once on startup. But I can't figure out how I'm supposed to do that? I've copied the code from the Beanshell Preprocessor I was using previously into a ".bshrc" file and updated the jMeter properties file with the location of my ".bshrc" file, but it doesn't seem to work. It doesn't actually seem to have done anything. When I run the test, no values are present and everything fails.
I've tried using:
beanshell.init.file=../bin/data.bshrc
and
beanshell.preprocessor.init=../bin/data.bshrc
I've tried to find some sort of idiots guide to setting up an init file, but I can't find anything helpful. This is the first time I've had to make much serious use of Beanshell and my Java knowledge is VERY limited at best!
At the moment, I'm getting round it by running my test once with the original Beanshell pre-processor enabled. This sets up the hashmaps and they stay resident in memory from there on. I stop this run, disable the pre-processor, and all subsequent runs work just fine.
Anyone?
I would suggest using setUp Thread Group which is being executed prior to any other Thread Groups and define your test data there with a Beanshell Sampler like
bsh.shared.myMap = new java.util.HashMap();
bsh.shared.myMap.put("foo","bar");
// any other operations
After that in your main Thread Group(s) you can access myMap values in any Beanshell-enabled test element (Sampler, Pre/Post Processor, Assertion) as
log.info("foo = " + bsh.shared.myMap.get("foo"));
2014/07/22 10:06:48 INFO - jmeter.util.BeanShellTestElement: foo = bar
See How to use BeanShell: JMeter's favorite built-in component guide for more details on Beanshell scripting in Apache JMeter and a kind of Beanshell cookbook.
If you use Beanshell for "heavy" operations I would recommend considering switching to JSR223 Sampler and Groovy language as in that case you'll get performance comparable to native Java code.
I'm trying to run around 15000 soap requests through JMeter. I have 15000 individual soap files in a folder.
I know that the WebService(SOAP) Request component has the option to point to a folder.
But, the problem is that the files in the folder will get picked up and run randomly and a file can get run multiple times.
This is not ideal because each request has a unique correlation id and if a file get's run twice, the second run will fail due to a duplicated correlation id.
Is there anyway, I could tell jmeter to run the files only once?
Also, as certain soap requests are dependent upon other request having already run, the ability to run these in a specified order would be desirable. Is this possible?
These seem like common problems that should have already been solved. But, I can't find much on google.
Do you guys have any ideas?
I would use the JSR223 Sampler to run a script (e.g. Groovy) to iterate through the files in the directory and store the text of each file in a String.
See, for example, this other answer about using a Groovy script to iterate a list of values.
You could put the data into a csv file and read it in using a CSV Data Set Config. If you need unique values over multiple threads then you have to create multiple files, one per thread.
You could also put the data in a database and use a JDBC Config/Sampler to access it, making sure to either a: delete the data after it is read, or b: mark it as 'read' using a flag. Both methods would prevent the same record being read twice by different threads.
If you need to run requests in order you should structure the test plan as such, requests will be made sequentially, top to bottom.