作者来自 Elastic Drew Tate 及 Matthias Wilhelm了解 Kibana 如何通过持续 polling 与浏览器端 HTTP/2 检测将 dashboard 加载时间最高缩短 25%并在 HTTP/1 环境下自动回退。使用单一解决方案即可实现数据观测、防护与搜索。从应用监控到威胁检测Kibana 是适用于关键使用场景的多功能平台。立即开始你的 14 天免费试用。得益于持续 pollingKibana 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 检查查询是否完成。传统 polling 策略在查询提交后我们会给 Elasticsearch 一小段时间尝试直接完成搜索并返回结果。如果搜索能在这段时间内完成那么整个过程就等同于一次简单的请求-响应。但对于耗时较长的搜索初始连接会被关闭随后 Kibana 开始周期性检查搜索是否完成。这一过程称为 polling。传统 polling 的性能缺陷查看上图后你可能已经能看出这种方法的性能问题搜索最有可能在 Kibana 的某个休眠间隔期间完成从而导致时间被浪费。传统 polling 的阴暗面在最糟糕的情况下当搜索恰好在某个休眠周期开始时完成整个 polling 间隔的时间都会被白白浪费。backoff 策略的影响在 polling 场景中应用 backoff 策略是一种标准实践。这意味着搜索持续时间越长我们进行 polling 的频率就越低。poll 间隔 backoff 调度策略然而这也意味着潜在的 “损失时间” 会随着查询持续时间增长而扩大。polling interval 如何形成锯齿状延迟模式把这些因素组合起来后我们的损失时间就会变成一个分段式的锯齿函数。查询耗时带来的时间损失在这里峰值代表最坏情况谷值代表最好情况。这说明传统 polling 的时间损失范围在 0 到完整 polling 间隔之间变化具体取决于查询持续时间以及网络状况。持续 pollingKibana 如何消除等待时间传统 polling 的问题在于 Kibana 与 Elasticsearch 之间缺乏协调。理想情况下Kibana 应该在结果可用的瞬间就立刻知道。那么如果我们反转 polling 模式让绝大部分时间用于检查 Elasticsearch而几乎不再进入 sleep 状态会怎样持续 polling一种消除等待时间的解决方案通过长轮询与取消 sleep 周期的组合结果可以在准备就绪的第一时间被返回。HTTP/1 性能退化理论是成立的。那么为什么当我们开启 continuous polling 时这个 Kibana 部署反而出现性能明显下降的现象关键在于这个部署运行在 HTTP/1 上。在 HTTP/1 中HTTP 请求与 TCP 连接是 1:1 映射的。因此多个长连接的 polling 请求会占用浏览器有限的连接池从而导致其他请求被排队。而在 HTTP/2 中不同的网络请求可以通过多路复用multiplexing共享同一个 TCP 连接因此不会出现这个问题。HTTP/1 与 HTTP/2 在 HTTP-TCP 映射上的差异因此在 HTTP/2 上 continuous polling 是一种优势但在 HTTP/1 上它反而变成了一个缺点。HTTP/1HTTP/2TCP 连接每个 HTTP 请求一个连接continuous polling 行为性能下降连接池耗尽Kibana 如何检测 HTTP 协议以选择最优 polling 策略HTTP/2 是推荐协议并且自 9.0 起已成为 Kibana 的默认配置因此不启用这一性能优化会非常可惜。另一方面HTTP/1 的体验退化非常明显如果在尚未升级协议的 on-prem 部署中误用 continuous polling会带来不可接受的性能风险。因此答案很明确Kibana 需要检测当前使用的协议并应用最优的 polling 策略。从技术上讲Kibana server 确实可以知道自己使用的 HTTP 协议。但这里有一个关键点真正的瓶颈在于浏览器的连接池。这意味着真正重要的是浏览器侧使用的协议。而由于 proxies 的存在这两者并不总是一致。每一跳网络network hop都可能使用不同的协议如果我们基于 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。按查询时长划分的 dashboard 加载时间模式与最初的 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 还是传统 pollingKibana 通过浏览器的 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
Kibana 将 dashboard 加载时间最高缩短 25% —— 其背后的 polling 策略揭秘
作者来自 Elastic Drew Tate 及 Matthias Wilhelm了解 Kibana 如何通过持续 polling 与浏览器端 HTTP/2 检测将 dashboard 加载时间最高缩短 25%并在 HTTP/1 环境下自动回退。使用单一解决方案即可实现数据观测、防护与搜索。从应用监控到威胁检测Kibana 是适用于关键使用场景的多功能平台。立即开始你的 14 天免费试用。得益于持续 pollingKibana 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 检查查询是否完成。传统 polling 策略在查询提交后我们会给 Elasticsearch 一小段时间尝试直接完成搜索并返回结果。如果搜索能在这段时间内完成那么整个过程就等同于一次简单的请求-响应。但对于耗时较长的搜索初始连接会被关闭随后 Kibana 开始周期性检查搜索是否完成。这一过程称为 polling。传统 polling 的性能缺陷查看上图后你可能已经能看出这种方法的性能问题搜索最有可能在 Kibana 的某个休眠间隔期间完成从而导致时间被浪费。传统 polling 的阴暗面在最糟糕的情况下当搜索恰好在某个休眠周期开始时完成整个 polling 间隔的时间都会被白白浪费。backoff 策略的影响在 polling 场景中应用 backoff 策略是一种标准实践。这意味着搜索持续时间越长我们进行 polling 的频率就越低。poll 间隔 backoff 调度策略然而这也意味着潜在的 “损失时间” 会随着查询持续时间增长而扩大。polling interval 如何形成锯齿状延迟模式把这些因素组合起来后我们的损失时间就会变成一个分段式的锯齿函数。查询耗时带来的时间损失在这里峰值代表最坏情况谷值代表最好情况。这说明传统 polling 的时间损失范围在 0 到完整 polling 间隔之间变化具体取决于查询持续时间以及网络状况。持续 pollingKibana 如何消除等待时间传统 polling 的问题在于 Kibana 与 Elasticsearch 之间缺乏协调。理想情况下Kibana 应该在结果可用的瞬间就立刻知道。那么如果我们反转 polling 模式让绝大部分时间用于检查 Elasticsearch而几乎不再进入 sleep 状态会怎样持续 polling一种消除等待时间的解决方案通过长轮询与取消 sleep 周期的组合结果可以在准备就绪的第一时间被返回。HTTP/1 性能退化理论是成立的。那么为什么当我们开启 continuous polling 时这个 Kibana 部署反而出现性能明显下降的现象关键在于这个部署运行在 HTTP/1 上。在 HTTP/1 中HTTP 请求与 TCP 连接是 1:1 映射的。因此多个长连接的 polling 请求会占用浏览器有限的连接池从而导致其他请求被排队。而在 HTTP/2 中不同的网络请求可以通过多路复用multiplexing共享同一个 TCP 连接因此不会出现这个问题。HTTP/1 与 HTTP/2 在 HTTP-TCP 映射上的差异因此在 HTTP/2 上 continuous polling 是一种优势但在 HTTP/1 上它反而变成了一个缺点。HTTP/1HTTP/2TCP 连接每个 HTTP 请求一个连接continuous polling 行为性能下降连接池耗尽Kibana 如何检测 HTTP 协议以选择最优 polling 策略HTTP/2 是推荐协议并且自 9.0 起已成为 Kibana 的默认配置因此不启用这一性能优化会非常可惜。另一方面HTTP/1 的体验退化非常明显如果在尚未升级协议的 on-prem 部署中误用 continuous polling会带来不可接受的性能风险。因此答案很明确Kibana 需要检测当前使用的协议并应用最优的 polling 策略。从技术上讲Kibana server 确实可以知道自己使用的 HTTP 协议。但这里有一个关键点真正的瓶颈在于浏览器的连接池。这意味着真正重要的是浏览器侧使用的协议。而由于 proxies 的存在这两者并不总是一致。每一跳网络network hop都可能使用不同的协议如果我们基于 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。按查询时长划分的 dashboard 加载时间模式与最初的 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 还是传统 pollingKibana 通过浏览器的 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
