Kibana reduz o tempo de carregamento do dashboard em até 25% — aqui está a estratégia de sondagem por trás disso

Os dashboards do Kibana e o Discover agora carregam até 25% mais rápido graças à sondagem contínua. Em vez de ficar em espera entre verificações periódicas, o Kibana agora mantém as conexões HTTP abertas e entrega os resultados das consultas do Elasticsearch no momento em que estão prontos. Em HTTP/2+ (o padrão do Kibana desde a versão 9.0), isso ocorre automaticamente, sem necessidade de configuração. Em HTTP/1, o Kibana recorre à sondagem tradicional para evitar o esgotamento do pool de conexão.

Como o Kibana busca dados ao carregar um dashboard

Quando um dashboard é aberto, a maioria dos painéis (internamente, chamamos esses incorporáveis) inicia uma ou mais consultas no Elasticsearch. Mas, em vez da simples chamada e resposta de uma busca síncrona (sync), usamos o poder da busca assíncrona (docs async).

Com a busca assíncrona, os resultados das consultas ficam disponíveis no Elasticsearch fora de qualquer requisição HTTP específica. Isso é importante porque

• torna o carregamento de dados resiliente à turbulência da rede

• potencializa nosso recurso de busca em segundo plano, o que permite que os usuários trabalhem em outras coisas no Kibana enquanto esperam por um dashboard de longa duração ou por uma sessão do Discover

Após a consulta inicial ser enviada, o Kibana monitora a busca para detectar quando ela está concluída e recuperar o conjunto de resultados.

Como a sondagem tradicional afeta os tempos de carregamento do dashboard do Kibana

Na sondagem tradicional, o Kibana envia uma consulta, fecha a conexão inicial e então verifica periodicamente a conclusão do Elasticsearch.

Damos ao Elasticsearch um curto período de tempo após o envio da consulta para simplesmente completar a busca e devolver os resultados. Se a busca for concluída tão rapidamente, isso se resume a uma simples chamada e resposta. Mas para buscas mais longas, a conexão inicial é fechada e o Kibana começa a verificar periodicamente a busca para conclusão. Isso é chamado de sondagem.

Desvantagens de desempenho da sondagem tradicional

Observando a figura acima, talvez você já possa ver a desvantagem de desempenho dessa abordagem: é mais provável que a busca termine durante um dos intervalos de espera do Kibana, levando à perda de tempo.

No pior cenário (quando uma busca é concluída no início de um período de espera), toda a duração do intervalo de sondagem será desperdiçada.

O impacto de uma estratégia de backoff

É prática padrão durante a sondagem aplicar uma estratégia de backoff. Isso significa que, quanto maior a duração da busca, menos frequentemente a consultamos.

No entanto, isso também significa que o tempo potencial perdido varia proporcionalmente com a duração da busca.

Como intervalos de sondagem criam padrões de latência em forma de serra

Ao combinar todos esses fatores, o tempo perdido passa a seguir um padrão em dente de serra escalonado.

Aqui, os picos são os piores cenários possíveis e os vales são os melhores cenários. Isso ilustra que a sondagem tradicional nos custa entre nada e a duração total do intervalo de sondagem, dependendo da duração da busca (e das condições da rede).

Sondagem contínuas: como o Kibana elimina o tempo de espera

O problema com a sondagem tradicional é uma falta fundamental de coordenação entre Kibana e Elasticsearch. Idealmente, o Kibana sabe imediatamente quando os resultados estão disponíveis. Então, e se invertêssemos o padrão de sondagem para que quase todo o tempo seja gasto checando o Elasticsearch e nenhum tempo seja gasto em espera?

Com esta combinação de sondagem longa e sem mais períodos de espera, os resultados são entregues assim que estiverem prontos.

Degradação HTTP/1

A teoria é sólida. Então, por que essa implantação do Kibana parece tão degradada quando ativamos a sondagem contínua?

A chave é que essa implantação está sendo executada em HTTP/1. No HTTP/1, as requisições HTTP são mapeadas 1:1 para conexões TCP. Portanto, várias solicitações de sondagem de longa duração estão monopolizando o pool de conexões finito do navegador, fazendo com que outras solicitações sejam colocadas na fila.

No HTTP/2+, por outro lado, as solicitações de rede podem compartilhar conexões TCP via multiplexação, então não enfrentamos esse problema.

Portanto, no HTTP/2+, a sondagem contínua é uma virtude, mas no HTTP/1 ela se torna um vício.

Como o Kibana detecta o protocolo HTTP para sondagem ideal

HTTP/2 é o protocolo recomendado e é o padrão do Kibana desde a versão 9.0, então seria uma pena não enviar esse aprimoramento de desempenho. Por outro lado, a experiência HTTP/1 é tão degradada que não é aceitável arriscar isso em implantações no local que ainda não atualizaram seu protocolo. A resposta é clara: precisamos detectar qual protocolo está em uso e aplicar a estratégia de sondagem ideal.

Certamente é possível que o servidor Kibana saiba qual protocolo ele utiliza. Mas há um porém: o fator limitante é o conjunto de conexões do navegador. Isso significa que o que realmente importa é o que o navegador utiliza.

Por causa dos proxies, nem sempre são iguais.

Se basearmos nossa otimização no protocolo do servidor, podemos errar de duas maneiras.

1. Aplicar sondagem contínua quando não deveria e isso prejudica a experiência.

2. Deixar de aplicar a sondagem contínua quando necessário e perder a otimização.

Felizmente, navegadores modernos oferecem uma forma de detectar o protocolo do último salto de rede de qualquer requisição concluída por meio do uso de um PerformanceObserver. Então, observamos o protocolo da primeira submissão de consulta e otimizamos com base nisso.

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);
  }
});

Resultados de laboratório: sondagem contínua vs. sondagem tradicional em Kibana

Para validar a sondagem contínua, criamos dashboards com atrasos de consulta variando de 1 a 23 segundos e medimos os tempos de carregamento com e sem a otimização ativada. Em seguida, carregamos os dashboards com e sem sondagem contínua para medir os ganhos (nos divertimos bastante com race-for-the-prize).

O padrão ecoa nosso diagrama dente de serra original. Para algumas durações de consulta, os ganhos são pequenos, enquanto para outras chegam a vários segundos.

Conclusão

Essa otimização substitui com sucesso a latência inerente à sondagem tradicional por uma estratégia de sondagem contínua mais eficiente. O principal desafio foi implementar essa otimização condicionalmente para evitar a degradação do desempenho em implantações HTTP/1. Resolvemos usando o PerformanceObserver do navegador para detectar de forma confiável o protocolo em uso no salto final da rede.

Testes laboratoriais validam a teoria, mostrando que a sondagem contínua entrega resultados assim que estão disponíveis. Em média, isso leva a uma melhoria significativa na experiência do usuário, tornando o carregamento de dados até 25% mais rápido.

Este trabalho é o passo mais recente em nosso compromisso de reduzir o tempo para obter insights para nossos usuários. Ao tornar o Kibana um proxy mais transparente para os dados do Elasticsearch, ultrapassamos os limites do desempenho dentro da nossa esfera de influência. Mais novidades em breve!

(Em 2025, Thomas Neirynk apresentou uma excelente visão geral dos métodos e da motivação por trás do aprimoramento do desempenho do dashboard do Kibana. Esta é uma atualização sobre essa iniciativa.)