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
The stdout of the wrk load generator is read by crank, and values fished out of stdout using regexps; matches are then turned into timestamped Events for the eventlogger, and eventually find their way to the json file produced by crank master.
Unfortunately, crank does not process each line of output from wrk "as soon as possible", but instead combines all lines into a single string, and when wrk is done, analyzes that string.
The timestamps in the Events represent the time of processing by crank, not the time they were read by crank. So all timestamps in the log are more or less the same time.
If wrk uses line buffering, and flushes after every line, can crank read the lines in real-time, with a slight delay?
I do not know if this architecture/limitation is shared by other subprocesses like wrk2.
The text was updated successfully, but these errors were encountered:
The stdout of the wrk load generator is read by crank, and values fished out of stdout using regexps; matches are then turned into timestamped Events for the eventlogger, and eventually find their way to the json file produced by crank master.
Unfortunately, crank does not process each line of output from wrk "as soon as possible", but instead combines all lines into a single string, and when wrk is done, analyzes that string.
The timestamps in the Events represent the time of processing by crank, not the time they were read by crank. So all timestamps in the log are more or less the same time.
If wrk uses line buffering, and flushes after every line, can crank read the lines in real-time, with a slight delay?
I do not know if this architecture/limitation is shared by other subprocesses like wrk2.
The text was updated successfully, but these errors were encountered: