While there is check in execute_load_generator() on $CMDLINE return code, it doesn't prevent the script continuing to call ~/cb_report_app_metrics.py to report metrics when return code is non-zero. Below is an example of ~/cb_report_app_metrics.py call in that case:
The code in ~/cb_report_app_metrics.py does have check against empty metric data, so throughput::tps, iterations::num, latency::msec are discarded. The reported metric is like the following:
I doubt if this is by design. In my opinion, the metric data is useless and should be skipped. Saving them in metric store is confusing.
BTW, due to the processing in update_avg_acc_max_min() running the above ~/cb_report_app_metrics.py multiple times generates different metrics, which is confusing too.
I observed the issue when trying to run Hadoop workload. Take its start script as an example:
While there is check in
execute_load_generator()
on$CMDLINE
return code, it doesn't prevent the script continuing to call~/cb_report_app_metrics.py
to report metrics when return code is non-zero. Below is an example of~/cb_report_app_metrics.py
call in that case:The code in
~/cb_report_app_metrics.py
does have check against empty metric data, sothroughput::tps
,iterations::num
,latency::msec
are discarded. The reported metric is like the following:I doubt if this is by design. In my opinion, the metric data is useless and should be skipped. Saving them in metric store is confusing.
BTW, due to the processing in
update_avg_acc_max_min()
running the above~/cb_report_app_metrics.py
multiple times generates different metrics, which is confusing too.