"Que tempos de resposta podemos esperar da sua API GraphQL?" 

Esta é provavelmente uma das perguntas mais frequentes que recebemos na Marketplacer em relação à nossa API GraphQL. É uma pergunta muito razoável, e nós compreendemos porque é que os nossos clientes a fazem, mas nem sempre é fácil de responder...

Neste artigo, partilhamos uma das abordagens que adoptámos para avaliar os tempos de resposta da API GraphQL na Marketplacer.

Mas primeiro, alguns antecedentes...

O "problema" com o GraphQL...

Toda a proposta de valor do padrão de design GraphQL (pelo menos para mim) é essa:

  • Evita a procura excessiva
  • Evita a sub-busca

Ou, dito de outra forma mais positiva, obtém-se exatamente a resposta ao payload que se pretende. A capacidade de escrever consultas e moldar o seu payload de acordo com as suas necessidades exactas é o que o torna uma proposta tão atractiva. Para ilustrar o que quero dizer, vejamos uma das consultas que oferecemos na Marketplacer: advertSearch.

Um "anúncio" na Marketplacer é, na realidade, apenas um produtomas por várias razões que não vou abordar aqui, chamamos-lhes "anúncios" na API GraphQL da Marketplacer.

O AdvertSearch permite aos consumidores da nossa API GraphQL puxar produtos alojados na Marketplacer para qualquer sistema a montante que necessite deles. Dois casos de utilização típicos seriam:

  • Para apresentar uma lista de produtos numa página de resultados de pesquisa
  • Para exibir uma única página de detalhes do produto (ou "PDP" no mundo do eCom)

Estes dois casos de utilização têm caraterísticas diferentes:

  • O 1º requer vários objectos, mas cada um com uma "pequena" quantidade de dados
  • O segundo requer apenas um objeto, mas com uma "grande" quantidade de dados

Em ambos os casos, pode utilizar a função advertSearch para obter esses dados, mas é seguro assumir que ambas as consultas teriam tempos de resposta semelhantes? Er, não, não seria...

Este enigma realmente nos traz de volta ao ponto de partida, e a pergunta: "Que tempos de resposta podemos esperar da sua API GraphQL?" Não há realmente uma resposta...

Perfis de consulta

Para tentar responder à questão dos tempos de resposta, concebemos uma série de "perfis de consulta" que tentam abranger uma série de casos de utilização comuns.

Em seguida, executamos cada um destes perfis de consulta numa cadência regular utilizando o K6(uma estrutura de teste de carga muito popular) e capturamos os dados resultantes para relatórios subsequentes. Isto não só nos dá uma resposta bastante decente à pergunta acima mencionada, mas também:

  • Permite-nos acompanhar os tempos de resposta ao longo do tempo
  • Introduzir facilmente novos perfis se os nossos clientes os solicitarem

As caraterísticas actuais dos nossos perfis incluem o seguinte:

  • Profundidade da consulta: Quantas ligações estamos a percorrer na consulta? Este valor varia de 1 para cima. Quanto mais "profunda" for a consulta, mais dispendiosa é, o que pode ter impacto nos tempos de resposta
  • Tamanho da página: Pedir um máximo de 10 resultados por página, em vez de 1000, tem implicações nos tempos de resposta
  • Filtros: Quantos filtros estão a ser aplicados com consultas de tipo de pesquisa?

Assim, por exemplo, eis 2 perfis de consulta para o advertSearch (temos muitos mais, mas estes são apenas 2 exemplos extremos):

  • Profundidade de 1 nível / 10 resultados por página / Sem filtragem
  • Profundidade de 2 níveis / 1000 resultados por página / 1x filtro

Como devem imaginar, o tempo de resposta da primeira consulta é inferior ao da segunda...

Medições efectuadas

Como mencionado, utilizamos o K6 como veículo principal para executar testes, sendo cada teste executado com os seguintes parâmetros:

  • Utilizadores virtuais (VUs): 1
  • Duração: 10s

Estas podem, obviamente, ser alteradas, mas para efeitos de avaliação comparativa, consideramos que está tudo bem. De seguida, reunimos as seguintes métricas a partir do resultado de cada teste:

  • Tempo médio de resposta
  • Tempo médio de resposta (as médias não são óptimas, mas registamo-las na mesma)
  • p(90): 90% dos pedidos devem ser mais rápidos do que a latência dada
  • p(95): 95% dos pedidos devem ser mais rápidos do que a latência dada

O K6 tem uma gama muito mais alargada de métricas disponíveis, mas, mais uma vez, só queríamos tentar responder a uma pergunta simples da forma mais simples possível...

Considerações finais

Como mencionado na introdução, empregamos algumas abordagens complementares para medir os tempos de resposta do GraphQL; no entanto, essa técnica nos dá um conjunto bem definido de testes que facilitam bastante as comparações pontuais.