You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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 atSession
.Example
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.
ac0001_us-central1_00/TCheckout/745/skus.log
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.
The text was updated successfully, but these errors were encountered: