"¿Qué tiempos de respuesta podemos esperar de su API GraphQL?". 

Esta es probablemente una de las preguntas más frecuentes que recibimos en Marketplacer en relación con nuestra API GraphQL. Es una pregunta muy razonable, y entendemos por qué la hacen nuestros clientes, pero no siempre es tan fácil de responder....

En este artículo, compartimos uno de los enfoques que hemos adoptado para la evaluación comparativa de los tiempos de respuesta de la API GraphQL en Marketplacer.

Pero antes, algunos antecedentes...

El "problema" con GraphQL...

Toda la propuesta de valor del patrón de diseño GraphQL (para mí al menos) es que:

  • Evita la sobrecarga
  • Evita la búsqueda insuficiente

O, por decirlo de otra forma más positiva, se obtiene exactamente la respuesta de carga útil que se desea. La capacidad de escribir consultas y adaptar la carga útil a sus necesidades exactas es lo que hace que sea una propuesta tan atractiva. Para ilustrar lo que quiero decir, echemos un vistazo a una de las consultas que ofrecemos en Marketplacer: advertSearch.

Un "anuncio" en Marketplacer es en realidad un productopero por varias razones que no trataré aquí, los llamamos "anuncios" en la API GraphQL de Marketplacer.

AdvertSearch permite a los consumidores de nuestra API GraphQL extraer productos alojados en Marketplacer a través de cualquier sistema ascendente que los necesite. Dos casos de uso típicos serían:

  • Para mostrar una lista de productos en una página de resultados de búsqueda
  • Para mostrar una única página de detalles del producto (o "PDP" en el mundo del eCom)

Estos dos casos tienen características diferentes:

  • La 1ª requiere varios objetos, pero cada uno con una "pequeña" cantidad de datos
  • El 2º requiere sólo 1 objeto, pero con una "gran" cantidad de datos

En ambos casos, puede utilizar la función advertSearch para obtener estos datos, pero ¿es seguro suponer que ambas consultas tendrán tiempos de respuesta similares? Pues no...

Este enigma realmente nos devuelve al punto de partida, y a la pregunta: "¿Qué tiempos de respuesta podemos esperar de su API GraphQL?" Realmente no hay 1 respuesta....

Perfiles de consulta

Para intentar responder a la pregunta sobre los tiempos de respuesta, hemos diseñado una serie de "perfiles de consulta" que intentan cubrir una serie de casos de uso habituales.

A continuación, ejecutamos cada uno de estos perfiles de consulta con una cadencia regular utilizando K6(un marco de pruebas de carga muy popular) y capturamos los datos resultantes para elaborar informes posteriores. Esto no sólo nos da una respuesta bastante decente (s) a la pregunta antes mencionada, pero también:

  • Nos permite hacer un seguimiento de los tiempos de respuesta a lo largo del tiempo
  • Introducir fácilmente nuevos perfiles si nuestros clientes lo solicitan

Las características actuales de nuestros perfiles son las siguientes:

  • Profundidad de la consulta: ¿Cuántas conexiones atravesamos en la consulta? Oscila entre 1 y más. Cuanto más "profunda" sea la consulta, más costosa será, lo que puede repercutir en los tiempos de respuesta.
  • Tamaño de página: Solicitar un máximo de 10 resultados por página, en lugar de 1.000, repercute en los tiempos de respuesta.
  • Filtros: ¿Cuántos filtros se aplican con las consultas de tipo búsqueda?

Así, por ejemplo, aquí hay 2 perfiles de consulta para advertSearch, (tenemos muchos más, pero estos son sólo 2 ejemplos extremos):

  • 1 Nivel de Profundidad / 10 Resultados por Página / Sin Filtro
  • Profundidad de 2 niveles / 1000 resultados por página / 1x filtro

Como seguro que puedes imaginar, el tiempo de respuesta de la 1ª consulta es inferior al de la 2ª...

Medidas tomadas

Como se ha mencionado, utilizamos K6 como vehículo principal para ejecutar las pruebas, y cada prueba se ejecuta con los siguientes parámetros:

  • Usuarios virtuales (VU): 1
  • Duración: 10s

Por supuesto, estos parámetros pueden modificarse, pero a efectos de evaluación comparativa, creemos que está bien así. A continuación, recopilamos las siguientes métricas a partir del resultado de cada prueba:

  • Tiempo medio de respuesta
  • Tiempo medio de respuesta (las medias no son muy buenas, pero las registramos de todos modos)
  • p(90): El 90% de las peticiones deben ser más rápidas que la latencia dada
  • p(95): El 95% de las peticiones deben ser más rápidas que la latencia dada

K6 dispone de una gama mucho más amplia de métricas, pero, de nuevo, sólo queríamos intentar responder a una pregunta sencilla de la forma más simple posible...

Reflexiones finales

Como mencionamos en la introducción, empleamos algunos enfoques complementarios para medir los tiempos de respuesta de GraphQL; sin embargo, esta técnica nos proporciona un conjunto bien definido de pruebas que facilitan bastante las comparaciones puntuales.