No results for

Powered byAlgolia

JavaScript Compatibility Mode

suggest edits

As of v0.26, k6 supports running test scripts with different ECMAScript compatibility modes using the run --compatibility-mode CLI option or K6_COMPATIBILITY_MODE environment variable.

Currently two modes are available:

Base

CLI Parameter
Environment Variable
$ k6 run --compatibility-mode=base script.js

Pure Golang JavaScript VM supporting ES5.1+. Use this mode if your scripts are already written using only ES5.1 features, or were previously transformed by Babel, to reduce startup time, RAM usage and improve performance. See the k6-es6 project for an example Webpack setup that does this transformation outside of k6.

⚠️ Disclaimer

Your mileage may vary while running --compatibility-mode=base and also importing external dependencies. For instance, xml2js and cheerio currently do not work, while lodash does.

Basic Example

base-example.js
1const http = require('k6/http');
2const k6 = require('k6');
3
4module.exports.options = {
5 vus: 10,
6 duration: '30s',
7};
8
9module.exports.default = function () {
10 http.get('http://test.k6.io');
11 k6.sleep(1);
12};

⚠️ About require()

Note that require() is a custom k6 implementation of module loading, which doesn't behave in the same way as the require() call in Node.js. Specifically, it only handles loading of built-in k6 modules, scripts on the local filesystem, and remote scripts over HTTP(S), but it does not support the Node.js module resolution algorithm.

Advanced Example

advanced-example.js
1const http = require('k6/http');
2const metrics = require('k6/metrics');
3const k6 = require('k6');
4
5module.exports.options = {
6 stages: [
7 { duration: '30s', target: 20 },
8 { duration: '1m30s', target: 10 },
9 { duration: '20s', target: 0 },
10 ],
11 thresholds: {
12 'failed requests': ['rate<0.1'],
13 },
14};
15
16const myFailRate = new metrics.Rate('failed requests');
17
18module.exports.default = function () {
19 const res = http.get('https://httpbin.test.k6.io/');
20 const checkRes = k6.check(res, {
21 'status was 200': function (r) {
22 return r.status == 200;
23 },
24 });
25 if (!checkRes) {
26 myFailRate.add(1);
27 }
28 k6.sleep(1);
29};

Extended

CLI Parameter
Environment Variable
$ k6 run --compatibility-mode=extended script.js

In case of syntax/parsing errors, the script will be transformed using Babel with specific plugins bringing the compatibility to ES2015(ES6)+. This means that features such as classes and arrow functions can be used. This does take some time to transpile and the produced code has slightly different line/column numbers.

Before k6 v0.31.0, core.js v2 and even more Babel plugins were also included in extended mode. This added around 2MB extra memory usage per VU and some of the transformations (generators, async/await) of Babel were not useful as they were still not enough for k6 to just work with those features. So, before v0.31.0, using --compatibility-mode=base was a significant improvement on memory usage, which also translated to some CPU gains.

Performance Comparison

There's a substantial difference in performance between both modes, as shown by GNU time below, especially when running tests with a large number of VUs:

Base Mode
Extended Mode
$ /usr/bin/time -v k6 run \
--compatibility-mode=base \
--vus 3500 \
--duration=60s \
script.js
[...]
User time (seconds): 15.10
System time (seconds): 10.02
Percent of CPU this job got: 40%
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:01.88
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 903612
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 1
Minor (reclaiming a frame) page faults: 352090
Voluntary context switches: 558479
Involuntary context switches: 4689
Swaps: 0
File system inputs: 0
File system outputs: 78856
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0