Ability to log custom data to a file and have that file accessible in the report

[rschwietzke]

Goal

Why need the ability to log custom data such as user names, SKUs or similar as part of a load test. This might be used later on for whatever purpose. Currently, this data ends in log files and will be parsed out. The log files are part of the result set and hence might be large.

Add an API to XLT that allows to log data into scopes which later on will be aggregated into files which will be available as part of a load test report, rather the result.

API

We will most likely add this to Session or make it a custom logger of some kind. Because logging is something different, we likely prefer something at Session.

DataLogger logger = Session.getDataManager().dataLogger(String scope);
logger.setHeader(String header);
logger.setExtension(String extension);
logger.setFilename(String filename);

logger.log(String msg);

Example

DataLogger logger = Session.getDataManager().dataLogger("users")
    .setHeader("username,password,email");
    .setExtension("csv");
    .setFilename("created-accounts");

logger.log("msmith,9172)(/84hsda,m.smith@example.com");

Session.getDataManager().dataLogger("users").log("tmayer,9sadfasdf28a,thomas.mayer@example.com");

// less boilerplate
Session.logData("users", "tmayer,9sadfasdf28a,thomas.mayer@example.com");

The header will be written if this logger was never used before, and it has to log the first line. If the logger is open, we don't log the header again. The header is optional. If not header is set, none is logged. Same applies to extension (txt by default) and filename (scope by default).

Normal logging rules apply: "but only if logging is enabled and the current time is inside the configured logging period."
The naming is not perfect because we already have logDataRecord(Data).

Same scope, same file.

Log count challenge

We might log per user and therefore we end up with many files at the end. This is for performance reason to avoid that we have to synchronize logging. Because it might mean we have 1k files open at once per scope for 1k users on a machine, it could become a problem (even though we have a high file quota limit). Imagine people opening several log scopes.

So, it might be useful to have a single file per agent per scope and we use the log4j framework for that and rely on its magic to keep things efficient when logging.

Aggregated Files

Because we don't know anything about the data that was logged, we simply zip them up and have basically a directory per agent and likely one file per scope. If we log per user and scope, we might have to add the username and user number as well to the directory hierarchy.

• Per user and scope skus: ac0001_us-central1_00/TCheckout/745/skus.log
• Per agent: ac0001_us-central1_00/skus.log

Report

The report should feature a new section under "Custom Values". This section will become "Custom Data" and feature the recorded values (like we already do) and a new section "Custom Files" (just a first idea). A table shows the scope, how much data was logged (the files size before compression), and a link to the file for download.