Nova criação de perfil e monitoramento no Couchbase Server 5.0 Preview

Quando estou escrevendo consultas N1QL, preciso entender o desempenho da minha consulta (e do meu cluster) para poder fazer melhorias e diagnosticar problemas.

Com esta última versão de desenvolvedor do Couchbase Server 5.0, algumas novas ferramentas foram adicionadas à sua caixa de ferramentas de escrita N1QL.

Primeiro, uma revisão.

Há várias maneiras de um desenvolvedor executar consultas N1QL.

Nesta postagem, usarei principalmente o Query Workbench.

Há dois catálogos de sistemas que já estão disponíveis para você no Couchbase Server 4.5, sobre as quais falarei hoje.

Ambos active_requests e completed_requests retornam não apenas o texto original da consulta N1QL, mas também informações relacionadas: tempo da solicitação, ID da solicitação, tempo de execução, consistência da varredura e assim por diante. Essas informações podem ser úteis. Aqui está um exemplo que analisa uma consulta simples (select * from travel-sample) enquanto estiver em execução, executando select * from system:active_requests;

Em primeiro lugar, gostaria de salientar que phaseTimes é uma nova adição aos resultados. É uma maneira rápida e simples de ter uma noção do custo da consulta sem examinar o perfil inteiro. Ele fornece o custo geral de cada fase da solicitação sem entrar em detalhes de cada operador. No exemplo acima, por exemplo, você pode ver que analisar levou 500µs e primaryScan levou 107,3891ms. Essas informações podem ser suficientes para você continuar sem se aprofundar em META().plan.

No entanto, com o novo META().planvocê pode obter informações muito detalhadas sobre o plano de consulta. Desta vez, executarei SELECT *, META().plan FROM system:active_requests;

A saída acima vem do Query Workbench.

Observe a nova parte do "plano". Ela contém uma árvore de operadores que se combinam para executar a consulta N1QL. O operador raiz é uma Sequence, que por sua vez tem uma coleção de operadores filhos, como Authorize, PrimaryScan, Fetch e possivelmente ainda mais Sequences.

Para obter essas informações ao usar o cbq ou a API REST, você precisará ativar o recurso "profile" (perfil).

Você pode fazer isso em cbq digitando set -profile timings; e, em seguida, executar sua consulta.

Você também pode fazer isso com a API REST por solicitação (usando o /query/service e passando um parâmetro querystring de profile=timingspor exemplo).

Você pode ativar a configuração para todo o nó fazendo uma solicitação POST para http://localhost:8093/admin/settings, usando a autenticação Basic e um corpo JSON como:

Observe o perfil configuração. Anteriormente, ela estava definida como desligada, mas eu a configurei como "timings".

Talvez você não queira fazer isso, especialmente em nós que estão sendo usados por outras pessoas e programas, pois isso afetará outras consultas em execução no nó. É melhor fazer isso por solicitação.

Isso também é o que o Query Workbench faz por padrão.

Há muitas informações em META().plan sobre como o plano é executado. Pessoalmente, prefiro ver uma versão gráfica simplificada dele no Query Workbench clicando no ícone "Plan" (que mencionei brevemente em um postagem anterior sobre o novo Console da Web do Couchbase UI).

Vamos dar uma olhada em um exemplo um pouco mais complexo. Para este exercício, estou usando o bucket de amostra de viagem, mas removi um dos índices (DROP INDEX travel-sample.def_sourceairport;).

Em seguida, executo uma consulta N1QL para encontrar voos entre São Francisco e Miami:

A execução dessa consulta (em minha máquina local de nó único) leva cerca de 10 segundos. Isso definitivamente não é um tempo aceitável, então vamos dar uma olhada no plano para ver qual pode ser o problema (eu o dividi em duas linhas para que as capturas de tela caibam na postagem do blog).

Observando esse plano, parece que as partes mais caras da consulta são as Filtro e o Aderir. JUNTAR As operações funcionam com chaves, portanto, normalmente devem ser muito rápidas. Mas parece que há um lote de documentos que estão sendo unidos.

O filtro (o ONDE parte da consulta) também está levando muito tempo. Ela está examinando o aeroporto de origem e aeroporto de destino campos. Observando outras partes do plano, vejo que há um PrimaryScan. Isso deve ser um sinal de alerta quando se está tentando escrever consultas de alto desempenho. PrimaryScan significa que a consulta não conseguiu encontrar um índice que não fosse o índice primário. Isso é mais ou menos o equivalente a uma "varredura de tabela" em termos de banco de dados relacional. (Talvez você queira eliminar o índice primário para que esses problemas sejam resolvidos mais rapidamente, mas esse é um assunto para outra ocasião).

Vamos adicionar um índice no aeroporto de origem e veja se isso ajuda.

Agora, ao executar a mesma consulta acima, obtenho o seguinte plano:

Essa consulta levou cerca de 100 ms (em minha máquina local de nó único), o que é muito mais aceitável. A consulta Filtro e o Aderir ainda ocupam uma grande porcentagem do tempo, mas graças ao IndexScan substituindo o PrimaryScanhá muito menos documentos com os quais esses operadores precisam lidar. Talvez a consulta possa ser aprimorada ainda mais com um índice adicional no aeroporto de destino campo.

A resposta para os problemas de desempenho nem sempre está no ajuste das consultas. Às vezes, talvez seja necessário adicionar mais nós ao cluster para resolver o problema subjacente.

Veja o PrimaryScan informações em META().plan. Aqui está um trecho:

O servTime indica quanto tempo o serviço de consulta gasta para esperar no armazenamento de dados de chave/valor. Se o valor servTime é muito alto, mas há um pequeno número de documentos sendo processados, o que indica que o indexador (ou o serviço de chave/valor) não consegue acompanhar o ritmo. Talvez eles tenham muita carga proveniente de outro lugar. Portanto, isso significa que algo estranho está sendo executado em outro lugar ou que seu cluster está tentando lidar com carga excessiva. Talvez seja hora de adicionar mais alguns nós.

Da mesma forma, o kernTime é o tempo gasto na espera de outras rotinas N1QL. Isso pode significar que outra coisa a jusante no plano de consulta tem um problema, ou que o nó de consulta está sobrecarregado com solicitações e está tendo que esperar muito.

O novo META().plan e a nova interface do usuário do plano se combinam no Couchbase Server 5.0 para aprimorar o processo de criação de perfil e escrita N1QL.

Fique atento ao Blog do Couchbase para obter informações sobre o que está por vir na próxima versão de desenvolvedor.

Interessado em experimentar alguns desses novos recursos? Faça o download do Couchbase Server 5.0 hoje!

Queremos feedback! As versões para desenvolvedores são lançadas todos os meses, portanto, você tem a chance de fazer a diferença no que estamos criando.

Insetos: Se você encontrar um bug (algo que está quebrado ou que não funciona como esperado), registre um problema em nosso Sistema JIRA em issues.couchbase.com ou envie uma pergunta no Fóruns do Couchbase. Ou entre em contato comigo com uma descrição do problema. Ficarei feliz em ajudá-lo ou enviar o bug para você (meus gerentes do Couchbase me cumprimentam sempre que envio um bom bug).

Feedback: Diga-me o que você acha. Algo de que você não gosta? Algo de que você realmente gosta? Está faltando alguma coisa? Agora você pode dar feedback diretamente do Console da Web do Couchbase. Procure pelo ícone no canto inferior direito da tela.

Em alguns casos, pode ser difícil decidir se o seu feedback é um bug ou uma sugestão. Use seu bom senso ou, novamente, sinta-se à vontade para entrar em contato comigo para obter ajuda. Eu quero ouvir de você. A melhor maneira de entrar em contato comigo é Twitter @mgroves ou envie-me um e-mail matthew.groves@couchbase.com.