作者：来自 Elastic Drew Tate 及 Matthias Wilhelm
了解 Kibana 如何通过持续 polling 与浏览器端 HTTP/2 检测，将 dashboard 加载时间最高缩短 25%，并在 HTTP/1 环境下自动回退。
使用单一解决方案即可实现数据观测、防护与搜索。从应用监控到威胁检测，Kibana 是适用于关键使用场景的多功能平台。立即开始你的 14 天免费试用。
得益于持续 polling，Kibana dashboards 与 Discover 现在加载速度最高提升 25%。Kibana 不再在周期性检查之间进入等待状态，而是保持 HTTP 连接持续打开，并在 Elasticsearch 查询结果准备就绪的瞬间立即返回结果。在 HTTP/2+（自 9.0 起为 Kibana 默认配置）环境下，该功能会自动启用且无需任何配置。而在 HTTP/1 环境下，Kibana 会自动回退到传统 polling，以防止连接池耗尽。
Kibana 在加载 dashboard 时如何获取数据
当一个 Dashboard 被打开时，大多数 panels（内部称为 embeddables ）会启动一个或多个 Elasticsearch 查询。但 Kibana 并不是使用同步搜索（ sync search ）那种简单的请求-响应模式，而是利用了异步搜索（ async search ）的能力（ docs ）。
在 async search 中，查询结果会在 Elasticsearch 中持续保留，而不依赖于某一个特定 HTTP 请求。这一点非常重要，因为它：
- 提升了数据加载对网络波动的容错能力
- 支撑了后台搜索功能，使用户能够在等待长时间运行的 dashboard 或 Discover 会话时继续在 Kibana 中处理其他工作
在初始查询提交后，Kibana 会持续监控该搜索，以检测其何时完成并获取结果集。
传统 polling 如何影响 Kibana dashboard 加载时间
在传统 polling 中，Kibana 会提交一个查询，然后关闭初始连接，接着周期性地向 Elasticsearch 检查查询是否完成。
在查询提交后，我们会给 Elasticsearch 一小段时间，尝试直接完成搜索并返回结果。如果搜索能在这段时间内完成，那么整个过程就等同于一次简单的请求-响应。但对于耗时较长的搜索，初始连接会被关闭，随后 Kibana 开始周期性检查搜索是否完成。这一过程称为 polling。
传统 polling 的性能缺陷
查看上图后，你可能已经能看出这种方法的性能问题：搜索最有可能在 Kibana 的某个休眠间隔期间完成，从而导致时间被浪费。
在最糟糕的情况下（当搜索恰好在某个休眠周期开始时完成），整个 polling 间隔的时间都会被白白浪费。
backoff 策略的影响
在 polling 场景中应用 backoff 策略是一种标准实践。这意味着搜索持续时间越长，我们进行 polling 的频率就越低。
然而，这也意味着潜在的 “损失时间” 会随着查询持续时间增长而扩大。
polling interval 如何形成锯齿状延迟模式
把这些因素组合起来后，我们的损失时间就会变成一个分段式的锯齿函数。
在这里，峰值代表最坏情况，谷值代表最好情况。这说明传统 polling 的时间损失范围在 0 到完整 polling 间隔之间变化，具体取决于查询持续时间（以及网络状况）。
持续 polling：Kibana 如何消除等待时间
传统 polling 的问题在于 Kibana 与 Elasticsearch 之间缺乏协调。理想情况下，Kibana 应该在结果可用的瞬间就立刻知道。那么，如果我们反转 polling 模式，让绝大部分时间用于检查 Elasticsearch，而几乎不再进入 sleep 状态，会怎样？
通过长轮询与取消 sleep 周期的组合，结果可以在准备就绪的第一时间被返回。
HTTP/1 性能退化
理论是成立的。那么，为什么当我们开启 continuous polling 时，这个 Kibana 部署反而出现性能明显下降的现象？
关键在于，这个部署运行在 HTTP/1 上。在 HTTP/1 中，HTTP 请求与 TCP 连接是 1:1 映射的。因此，多个长连接的 polling 请求会占用浏览器有限的连接池，从而导致其他请求被排队。
而在 HTTP/2+ 中，不同的网络请求可以通过多路复用（multiplexing）共享同一个 TCP 连接，因此不会出现这个问题。
因此，在 HTTP/2+ 上 continuous polling 是一种优势，但在 HTTP/1 上它反而变成了一个缺点。
| HTTP/1 | HTTP/2+ |
|---|---|
| TCP 连接 | 每个 HTTP 请求一个连接 |
| continuous polling 行为 | 性能下降（连接池耗尽） |
Kibana 如何检测 HTTP 协议以选择最优 polling 策略
HTTP/2 是推荐协议，并且自 9.0 起已成为 Kibana 的默认配置，因此不启用这一性能优化会非常可惜。另一方面，HTTP/1 的体验退化非常明显，如果在尚未升级协议的 on-prem 部署中误用 continuous polling，会带来不可接受的性能风险。因此，答案很明确：Kibana 需要检测当前使用的协议，并应用最优的 polling 策略。
从技术上讲，Kibana server 确实可以知道自己使用的 HTTP 协议。但这里有一个关键点：真正的瓶颈在于浏览器的连接池。这意味着，真正重要的是浏览器侧使用的协议。
而由于 proxies 的存在，这两者并不总是一致。
如果我们基于 server 侧的协议来做优化，就可能出现两种错误：
- 在不应该使用 continuous polling 的情况下启用它，从而导致体验下降。
- 在应该使用 continuous polling 的情况下没有启用，从而错过性能优化。
幸运的是，现代浏览器提供了一种方式，可以通过 PerformanceObserver 来检测任意已完成请求的最后一跳网络协议。这样我们就可以观察第一次查询提交时的协议，并据此进行优化。
new PerformanceObserver((list) => { const entries = list.getEntries(); const entry = entries.find(({ name }) => name.includes('/internal/search/')); if (entry) { this.protocolSupportsMultiplexing = ['h2', 'h3'].includes(entry.nextHopProtocol); } });实验结果：Kibana 中 continuous polling vs. 传统 polling
为了验证 continuous polling 的效果，我们构建了包含不同查询延迟（1 到 23 秒）的 dashboards，并在启用与未启用该优化的情况下分别测量加载时间。随后，我们在开启与关闭 continuous polling 的条件下加载这些 dashboards，以评估性能收益（整个过程我们也玩得很开心，比如 race-for-the-prize）。
模式与最初的 sawtooth 图完全一致。在某些查询时长下，收益较小，而在另一些情况下则可以节省数秒级的时间。
结论
这一优化成功用更高效的 continuous polling 策略替代了传统 polling 中固有的延迟。其主要挑战在于如何进行条件化实现，以避免在 HTTP/1 部署中引发性能退化。我们通过浏览器的 PerformanceObserver 来可靠检测最终网络跳数的协议，从而解决了这个问题。
实验室测试验证了这一理论：continuous polling 能在结果准备好后立即返回。在平均情况下，这带来了显著的用户体验提升，使数据加载速度最高提升 25%。
这项工作是我们持续降低用户 “获取洞察时间” 的最新一步。通过让 Kibana 更透明地代理 Elasticsearch 数据，我们不断突破自身可控范围内的性能极限。未来还会有更多优化！
（2025 年 Thomas Neirynk 对 Kibana dashboard 性能优化的方法与动机做了精彩概述。本文是对该计划的更新。）
常见问题
continuous polling 如何提升 Kibana dashboard 加载性能？
dashboard 加载速度取决于 Kibana 从 Elasticsearch 获取查询结果的速度。传统 polling 会周期性检查是否完成，从而引入延迟。HTTP/2+ 下 Kibana 会自动启用 continuous polling，通过保持连接打开，在结果准备好时立即返回，从而减少延迟。
什么是 continuous polling，它如何提升 Kibana 性能？
continuous polling 反转了传统模式：不再在轮询之间 sleep，而是保持 HTTP 连接持续打开等待 Elasticsearch 返回结果。这消除了等待间隙，使 dashboard 和 Discover 更快返回结果。
continuous polling 是否适用于 HTTP/1 连接？
不适用。continuous polling 仅在支持 multiplexing 的 HTTP/2+ 连接上启用，以避免浏览器连接池耗尽。在 HTTP/1 上 Kibana 会自动回退到传统 polling。
continuous polling 能让 Kibana dashboard 快多少？
实验室测试显示，根据查询时长不同，dashboard 加载速度最多可提升 25%。长查询收益更明显，短查询差异较小。
Kibana 如何判断使用 continuous 还是传统 polling？
Kibana 通过浏览器的 PerformanceObserver API 检测首个请求的 HTTP 协议。如果是 HTTP/2 或 HTTP/3，则启用 continuous polling；如果是 HTTP/1，则使用传统 polling。
如果我遇到 timeout 怎么办？
如果 proxy 使用 HTTP/2+ 但 timeout 小于 30 秒，会导致 search timeout。可以增加 proxy timeout，或在 kibana.yml 中将 data.asyncSearch.pollLength 调低以匹配超时限制。
原文：https://www.elastic.co/search-labs/blog/kibana-dashboard-rendering-time
