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
Thanks for the suggestion, an interesting benchmark. Maybe one day we'll find time to run it or similar one, but to be honest I don't see a lot of value.
The things we focus on (multi-level multi-tenancy with fair resource budgeting, low query latency under mixed read-heavy workloads, space-efficient long-term storage with automatic downsampling) are quite different from the things being measured here, and will be much harder to quantatively benchmark. Highlighting only the raw throughput (even though I believe should be excellent in StatsHouse) does not do StatsHouse justice.
I think that it is possible to measure low query latency, space efficiency and down-sampling.
System performance under high multi-tenant load should demonstrate statshouse overall superiority and resiliency for overloads.
This will be a pretty strong argument for using statshouse instead of existing systems, people love benchmarks.
I understand that advanced benchmarks are hard to setup, but I think that profit worth the effort.
You can use VictoriaMetrics/prometheus-benchmark.
From project README:
Prometheus-benchmark provides the following features:
This is the most frequently used exporter for Prometheus metrics.
node_exporter
metrics - see chart/files/alerts.yaml.via scrapeConfigUpdatePercent
and scrapeConfigUpdateInterval
options. The churn rate is typical for Kubernetes monitoring.
under
remoteStorages
section at chart/values.yaml.The following systems can be tested with prometheus-benchmark:
So, list of compatible systems:
The text was updated successfully, but these errors were encountered: