changing defaults

[ppisljar]

Summary

resolves #157837

the defaults were updated:

• wait_for_completion is increased to 200ms (from 100ms). this gives es more time to provide initial response before starting the pooling. With this change most responses in our sample dashboards are actually returned in this first response, which improves time to data from 1.2seconds to 0.3seconds in my local tests
• poolling logic was updated so it does faster polling in the firs 2s after request was sent. Rather than waiting 1s before pools it waits only 300ms, which leads to actual pools sent out every 500ms (wait_for_completion time + poll interval)

to test i used shard delay aggregation to simulate slower responses
(add data.search.aggs.shardDelay.enabled: true to kibana.dev.yml` and use legacy visualizations and add a chart split with aggregation shard delay before adding anything else to the chart)

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[dej611]

The code looks fine 👍

I've tried to test both locally and in remote CCS and could not see any particular worsening of the performance. Perhaps this could be better measured in a deployed scenario.

[davismcphee]

These changes seem reasonable to me but I'm not super familiar with this code overall. WDYT @lukasolson?

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: d43b049

Failed CI Steps

• Serverless Security Investigations Cypress Tests #2

Metrics [docs]

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
data	408.3KB	408.3KB	+23.0B

History

• 💔 Build #155945 failed 93cebe3
• 💚 Build #154077 succeeded d854763
• 💔 Build #154035 failed 6e283623e414cf19cdbe1772a77929eabeccb60f

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream