CSV output

[rvagg]

Closes: #7

And a more configurable loadtest.sh so you can run it without certain tests and adjust the parameters of the tests with env vars.

The output file is out/results.csv; thoughts on a better name? Should we put it in the top-level directory instead and give it a date name so it persists?

Will post an example output when I get a complete run done on sp0.

[rvagg]

Here's a compiled results.csv, without the 64vu full-fetch version because I don't want to stay up late waiting for it.

results.csv

One thing I don't have is the delta values; should I put those in? A new column named Difference from HTTPS where it's 0 for the HTTP scenarios? I'm not sure it's worth it, you can derive that pretty easily in your spreadsheet program.

[kylehuntsman]

Not to completely throw all of this out, but apparently there are also K6 lifecycle function hooks that provide the test data as an argument. Instead of parsing JSON files at the end of all tests, we could just write to the end of an existing CSV file after each test. Thoughts?

It might be a little cleaner in that all script logic is in script.js. Could also avoid parsing JSON files and just focus on what's being written for each test run. There would be some logic to handle writing to the CSV file, which I don't even know if that's possible because of the lack of node access in the script.

[rvagg]

we could just write to the end of an existing CSV file after each test. Thoughts?

Yeah, or we could even just do that it handleSummary() too I think?

One problem with that approach is state management between runs, not a big deal, it'd basically boil down to "does the file exist? if not, then write the header". We'd also have to make sure we remove the CSV between runs along with the JSON in this case because it'll just keep on stacking.

The other problem, which is a bit bigger, is that you can't directly write files apparently: https://github.com/grafana/k6/issues/666

Unfortunately there's no way to write directly to the filesystem. That's mostly because of security and portability concerns when dealing with the distributed cluster and cloud execution.

You can use an extension: https://github.com/avitalique/xk6-file but that has to be built in to k6, using xk6. But I think we're going to be doing that when we end up with a bitswap extension .. maybe?

IMO it's just cleaner to do this this way. The logic is all portable if we do it another way, the most relevant bits are in processInput which takes a data object that should be the same as if it's run inside k6 anyway.

Latest push irons out the commit duplication.

[rvagg]

heh, derp, that's a bit embarrassing, but in my defence you did include both of these "leave blank" columns and TTFB and the new bandwidth columns in your original post in #7!

fixed, merging