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
Since v0.4.0, the prometheus parser trims the _total suffix from counter metric names, this is a breaking change for few projects.
An alternative, would be using the openmetrics.parser instead but unfortunately it's very slow compared to the prometheus parser, as the following logic #282 that optimized the prometheus parser wasn't reused in the new openmetrics.parser.
Implementing the same optimization logic for openmetrics.parser would enhance considerably the parser's performance (~3.3x perf enhancement for the KSM metric example) and would make it close to the prometheus parser. I tried some tests and I got promising results.
Here is some benchmark using timeit:
call (x100000): _parse_sample('simple_metric 1.513767429e+09')
Simple example with prometheus parser: 0.2489180564880371
Simple example with openmetrics parser: 1.1144659519195557
Simple example with the optimized openmetrics parser: 0.5948491096496582
call (x100000): _parse_sample('kube_service_labels{label_app="kube-state-metrics",label_chart="kube-state-metrics-0.5.0",label_heritage="Tiller",label_release="ungaged-panther",namespace="default",service="ungaged-panther-kube-state-metrics"} 1')
KSM metric example with prometheus parser: 1.6796550750732422
KSM metric example openmetrics parser: 6.6183180809021
KSM metric example optimized openmetrics parser: 2.0289480686187744
Would you support optimizing openmetrics.parser ?
Thanks!
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Hi,
Since v0.4.0, the prometheus parser trims the
_total
suffix from counter metric names, this is a breaking change for few projects.An alternative, would be using the
openmetrics.parser
instead but unfortunately it's very slow compared to the prometheus parser, as the following logic #282 that optimized the prometheus parser wasn't reused in the newopenmetrics.parser
.Implementing the same optimization logic for
openmetrics.parser
would enhance considerably the parser's performance (~3.3x perf enhancement for the KSM metric example) and would make it close to the prometheus parser. I tried some tests and I got promising results.Here is some benchmark using
timeit
:Would you support optimizing
openmetrics.parser
?Thanks!
The text was updated successfully, but these errors were encountered: