Hello,
I just want some clarification regarding setting some environment variables in the scenario options.
Consider this script
import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
scenarios: {
fooScenario: {
executor: 'constant-vus',
duration: '10s',
vus: 1,
env: { TESTVAR: 'footestvar' }
},
barScenario: {
executor: 'constant-vus',
duration: '10s',
vus: 1,
env: { TESTVAR: 'bartestvar' }
}
}
};
console.log(__ENV.TESTVAR); //undefined
console.log(__ENV.CLIVAR); //clivar
export default function () {
console.log(__ENV.TESTVAR); // footestvar or bartestvar
http.get('https://test.k6.io');
sleep(1);
}
running with k6 run -e CLIVAR=clivar .\script.js
command
Am I correct in assuming that during the VU’s init phase, the environment variables that are set by the scenarios are not yet accessible?
Hi @m.jurgilas,
welcome to the k6 community forum
yes, you’re right. They will be available from the defined exec
function, the default
in your case. Did you expect a different logic?
Since I’m not a JS dev and don’t know all the nuances of the language, I thought maybe there will be some magic and it will just work .
I’m experimenting with moving some JMeter tests to k6. What I wanted to accomplish is to define a filename variable for each scenario so that during the init phase, the VU would open that one specific file for uploading with FormData. Right now I have to open all the possible files using open()
in the init phase, and then take the appropriate file in the VU’s exec function by matching with the filename env variable. This wastes quite a lot of memory.
I can see that there is a PR that tries to mitigate that problem, but it’s still in progress.
Currently when I try running 160 VUs (80 which upload a 266kb file and 80 which upload a 757kb file) I’m getting 5-8GB of memory usage.
Maybe I’m approaching this situation completely wrong?
How many files are you opening in total?
Your approach is right. The unique alternative is to split the scenario into different tests and pass the file via env, for something more advanced in your case we need to implement #785 and #1931 that are already in our priorities.
1 Like