Currently in Kibana there is no established and documented approach for microbenchmarking.
With the on-going effort to improve and monitor Kibana performance, it would be nice to adopt a microbenchmarking library for the Kibana repo and start using it consistently for adhoc microbenchmarks during feature development in known performance bottleneck areas.
For example, in App Services, some areas were we would benefit from microbenchmarking: KQL parsing, Data View initialisation and field list processing, expression execution pipeline. We would like to capture performance regressions in this areas during development, but this likely isn't something that should be captured with EBT and single-user-jounrey performance tests.
Stage 1 could be: Adopt a microbenchmarking library (TBD) for the Kibana repo and start using it consistently for adhoc microbenchmarks. Document and teach on how and when to use it
Stage 2 (later if there is a need and want for it): Integrate with other Kibana test/performance tooling and CI pipeline.
From @danielmitterdorfer on ES experience with microbenchmarking: microbenchmarks were useful though during development of a feature or when doing an investigation. A low friction option would be to adopt a microbenchmarking library for the Kibana repo and using it consistently when doing such adhoc microbenchmarks.
Also, the reason why microbenchmark trends were not useful in ES was that there was an extensive suite of macrobenchmarks that already helped to identify regressions. So people only looked at them and ignored the microbenchmarks.
Describe the feature:
Currently in Kibana there is no established and documented approach for microbenchmarking. With the on-going effort to improve and monitor Kibana performance, it would be nice to adopt a microbenchmarking library for the Kibana repo and start using it consistently for adhoc microbenchmarks during feature development in known performance bottleneck areas.
For example, in App Services, some areas were we would benefit from microbenchmarking: KQL parsing, Data View initialisation and field list processing, expression execution pipeline. We would like to capture performance regressions in this areas during development, but this likely isn't something that should be captured with EBT and single-user-jounrey performance tests.
cc @danielmitterdorfer @lizozom