"Quels sont les temps de réponse que nous pouvons attendre de votre API GraphQL ? 

C'est probablement l'une des questions les plus fréquemment posées à Marketplacer concernant notre API GraphQL. C'est une question très raisonnable, et nous comprenons pourquoi nos clients la posent, mais il n'est pas toujours facile d'y répondre...

Dans cet article, nous partageons l'une des approches que nous avons adoptées pour évaluer les temps de réponse de l'API GraphQL chez Marketplacer.

Mais d'abord, un peu d'histoire...

Le "problème" avec GraphQL...

L'ensemble de la proposition de valeur du modèle de conception GraphQL (pour moi en tout cas) est la suivante :

  • Il permet d'éviter les recherches excessives
  • Il permet d'éviter la sous-récupération des données

Ou, pour le dire d'une autre manière plus positive, vous obtenez exactement la réponse que vous souhaitez. La possibilité d'écrire des requêtes et de façonner votre charge utile en fonction de vos besoins exacts est ce qui en fait une proposition si attrayante. Pour illustrer ce que je veux dire, examinons l'une des requêtes que nous proposons chez Marketplacer : advertSearch.

Une "annonce" dans Marketplacer est en fait simplement un produitUn produit, mais pour diverses raisons que je n'aborderai pas ici, nous l'appelons "annonce" dans l'API GraphQL de Marketplacer.

AdvertSearch permet aux consommateurs de notre API GraphQL d'extraire les produits hébergés dans Marketplacer vers n'importe quel système en amont qui en a besoin. Deux cas d'utilisation typiques seraient :

  • Pour afficher une liste de produits sur une page de résultats de recherche
  • Pour afficher une seule page détaillée de produit (ou "PDP" dans le monde de l'eCom)

Ces deux cas d'utilisation présentent des caractéristiques différentes :

  • Le premier nécessite plusieurs objets, mais chacun avec une "petite" quantité de données.
  • Le deuxième ne nécessite qu'un seul objet, mais avec une "grande" quantité de données.

Dans les deux cas, vous pouvez utiliser la fonction advertSearch pour obtenir ces données, mais peut-on supposer que les deux requêtes auront des temps de réponse similaires ? Euh, non...

Cette énigme nous ramène à notre point de départ et à la question suivante : "Quels sont les temps de réponse que nous pouvons attendre de votre API GraphQL ?" Il n'y a pas vraiment de réponse...

Profils d'interrogation

Pour tenter de répondre à la question des temps de réponse, nous avons conçu un certain nombre de "profils d'interrogation" qui tentent de couvrir une série de cas d'utilisation courants.

Nous avons ensuite exécuté chacun de ces profils d'interrogation à une cadence régulière en utilisant le logiciel K6(un cadre de test de charge très populaire) et capturons les données résultantes en vue d'un rapport ultérieur. Cela nous permet non seulement d'obtenir une ou plusieurs réponses relativement décentes à la question susmentionnée, mais aussi de

  • Permet de suivre les temps de réponse dans le temps
  • Introduire facilement de nouveaux profils si nos clients en font la demande

Les caractéristiques actuelles de nos profils sont les suivantes :

  • Profondeur de la requête : Combien de connexions sont parcourues dans la requête ? Ce nombre varie de 1 à plus. Plus la requête est "profonde", plus elle est coûteuse, ce qui peut avoir un impact sur les temps de réponse.
  • Taille de la page : Le fait de demander un maximum de 10 résultats par page, au lieu de 1000, a des conséquences sur les temps de réponse.
  • Filtres : Combien de filtres sont appliqués aux requêtes de type recherche ?

Voici, par exemple, deux profils de requête pour advertSearch (nous en avons beaucoup d'autres, mais il ne s'agit que de deux exemples extrêmes) :

  • 1 niveau de profondeur / 10 résultats par page / Pas de filtrage
  • Profondeur à 2 niveaux / 1000 résultats par page / 1x filtre

Comme vous pouvez l'imaginer, le temps de réponse de la première requête est inférieur à celui de la deuxième...

Mesures prises

Comme nous l'avons mentionné, nous utilisons K6 comme principal véhicule pour effectuer des tests, chaque test étant exécuté avec les paramètres suivants :

  • Utilisateurs virtuels (VU) : 1
  • Durée : 10s

Ceux-ci peuvent, bien entendu, être modifiés, mais à des fins d'analyse comparative, nous estimons que c'est correct. Nous recueillons ensuite les mesures suivantes à partir des résultats de chaque test :

  • Temps de réponse médian
  • Temps de réponse moyen (les moyennes ne sont pas excellentes, mais nous les saisissons quand même)
  • p(90) : 90% des requêtes doivent être plus rapides que la latence donnée
  • p(95) : 95% des requêtes devraient être plus rapides que la latence donnée

K6 dispose d'une gamme beaucoup plus large de métriques, mais encore une fois, nous voulions simplement essayer de répondre à une question simple de la manière la plus simple possible...

Réflexions finales

Comme nous l'avons mentionné dans l'introduction, nous utilisons des approches complémentaires pour mesurer les temps de réponse GraphQL ; cependant, cette technique nous donne un ensemble de tests bien définis qui rendent les comparaisons ponctuelles assez faciles.