Summary
experiment_run_clickhouse.py had no resource-monitoring support, so ClickHouse/SQL experiments never produced monitor_output.json and analyze_monitor_output.py had nothing to read. Only experiment_run_e2e.py wired in RemoteMonitorService. This adds the same capability to the ClickHouse runner behind a config flag, generalizing remote_monitor.py / RemoteMonitorService to support a ClickHouse (non-Prometheus) backend.
Motivation
Latency and query-accuracy comparisons (compare_latencies.py, compare_query_results.py) work for ClickHouse experiments, but CPU/memory profiling did not, because the runner never launched remote_monitor.py. Resource cost is needed to compare baseline (ClickHouse) vs sketchdb at different data rates.
Acceptance criteria
Related
- Mirrors monitoring wiring in
experiment_run_e2e.py.
- Complements existing ClickHouse latency/query-result comparison tooling.
Summary
experiment_run_clickhouse.pyhad no resource-monitoring support, so ClickHouse/SQL experiments never producedmonitor_output.jsonandanalyze_monitor_output.pyhad nothing to read. Onlyexperiment_run_e2e.pywired inRemoteMonitorService. This adds the same capability to the ClickHouse runner behind a config flag, generalizingremote_monitor.py/RemoteMonitorServiceto support a ClickHouse (non-Prometheus) backend.Motivation
Latency and query-accuracy comparisons (
compare_latencies.py,compare_query_results.py) work for ClickHouse experiments, but CPU/memory profiling did not, because the runner never launchedremote_monitor.py. Resource cost is needed to compare baseline (ClickHouse) vs sketchdb at different data rates.Acceptance criteria
flow.remote_monitor=trueproducesmonitor_output.jsonfor both baseline and sketchdb.analyze_monitor_output.pyconsumes it and emits CPU/memory stats + plots.flow.remote_monitor=false(default) leaves existing behavior unchanged.experiment_run_e2e.py(sharedRemoteMonitorService/remote_monitor.py).Related
experiment_run_e2e.py.