Mondeca

Making Sense of Content

Benchmark de AWS Neptune 1.0

Photo by Florian Olivo on Unsplash

Dans cet article, nous continuons notre série de test sur AWS Neptune (Cf. notre dernier article) en faisant nos tests sur la version plus récente de Neptune, sortie en juillet 2018. Nous partons sur les mêmes hypothèses en ce qui concerne les données RDF de l’OPOCE , les configurations machines dans le cloud AWS, ainsi que les requêtes SQL mises en oeuvre. Le but de cet exercice étant de comparer Neptune 1.0 avec la version “Preview”. En théorie, nous attendons des améliorations de performance avec la nouvelle version de Neptune. Il faut préciser que pour respecter la reproducibilité des résultats, nous avons décidé de créer l’instance de test dans la région US East (N. Virginia)

Bench sur les requêtes de visualisation

Ce sont les requêtes (20 au total) dont le temps d’exécution ne doit pas dépasser 60s par requête. Nous utilisons la même méthodologie de bench comme mentionnée dans ce post. Ci-dessous la Figure 1 donne les temps de réponse en secondes.

Figure 1: Temps de réponse pour les requêtes du groupe 1 pour Neptune 1 (colonne 3). La colonne 2 donne les temps obtenus avec la version “Preview”. Notons qu’un temps supérieur à 60s n’est pas considéré comme “rapide” pour ce types de requêtes. La colonne 4 donne la différence des temps pour chaque requête.

Les résultats de la Figure 1 permettent de conclure ce qui suit:

  • Globalement, l’engin de Neptune 1.0 est plus rapide que sa version Preview.
  • On a moins de “Timeout” dans les requêtes ( 7 au lieu de 9) avec Neptune 1.0. Par exemple, la Q6 qui se terminait en un temps supérieur au timeout, prend visiblement trois fois moins de temps (20s).

Bench sur les requêtes analytiques

Ce sont des requêtes d’analyse de données, dont le temps d’exécution ne doit pas dépasser 600s (soit 6min). Pour notre test, elles sont au nombre de 24 au total. La Figure 2 ci-dessous donne les résultats obtenus dans notre scénario.

  • Les résultats de la Figure 2 pour les requêtes analytiques montrent clairement que l’engin de Neptune 1.0 est beaucoup plus lent que sa version Preview.
  • La différence peut parfois aller de 4X à 21X plus lent (respectivement pour Q10 et Q12).

Cet article montre que pour notre scénario, l’engin de Neptune 1.0 n’a pas totalement permis d’être plus rapide par rapport à sa version Preview. Il serait donc intéressant de faire une étude plus détaillée des lenteurs dans les requêtes analytiques afin de trouver des patterns faisant “ralentir” Neptune 1.0

En conclusion, pour prendre une image de l’athlétisme, l’engin de Neptune 1.0 serait approprié pour les sprints (courses de vitesse), pendant que aurait de la peine avec des courses de fond. Evidemment, sur la base de notre scénario.

Ghislain A.

Requêtes SPARQL avec Neptune

Dans le premier post nous avons vu comment configurer et charger des données RDF avec Amazon Neptune. Dans ce post, nous allons faire des tests d’exécution des requêtes SPARQL et mesurer les temps de réponse moyens. Les données sont basées sur le modèle FRBR ( un modèle conceptuel de données bibliographiques élaboré par un groupe d’experts de l’IFLA)  avec une ontologie propre nommée CDM.

Pour notre benchmark, nous allons utiliser un outil de benchmark assez facile à configurer, SPARQL Query Benchmarker . Evidemment, il existe d’autres outils plus sophistiqués comme celui-ci. Le but du jeu est de voir dans notre scenario si le moteur AWS Neptune tend plus vers une Lamborghini ou plutôt vers une R4. 🙂

SPARQL est le langage de requêtes des bases RDF, dont la spécification est faite par le W3C.

Requêtes SPARQL

Grâce à la générosité de l’Office de Publications, nous avons eu accès à des requêtes SPARQL utilisées en production. Ainsi, nous avons pu distinguer deux classes en fonction de leurs complexitiés. Evidemment, cette complexité implique différents délais de réponse attendus du moteur SPARQL. Ces classes de requêtes sont les suivantes:

  • Requêtes instantanées: Ce sont des requêtes qui permettent par exemple de construire de manière dynamique des pages HTML, comme celle-ci. Elles doivent donc avoir des temps de réponses de moins de 60 secondes. Un exemple est cette requête (Listing 1)  pour retrouver les titres et les résumés en francais du document avec identifiant celex 52011DC0666. Pour notre test, nous avons 20 requêtes dans cette classe.

Listing 1 – Exemple de requête instantanée

prefix cdm: <http://publications.europa.eu/ontology/cdm#>
prefix owl: <http://www.w3.org/2002/07/owl#>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT DISTINCT ?summary ?title WHERE { ?sum owl:sameAs ?summary. FILTER (REGEX(?summary, '/resource/uriserv/')).
OPTIONAL {?sum ^cdm:expression_belongs_to_work ?e. ?e cdm:expression_uses_language <http://publications.europa.eu/resource/authority/language/FRA>; cdm:expression_title ?title.}
{ SELECT DISTINCT ?sum WHERE { ?s cdm:resource_legal_id_celex "52011DC0666"^^xsd:string; ^cdm:summary_summarizes_work ?sum. }} }

Requêtes analytiques: Ce sont des requêtes permettant de faire des validations et des contrôles sur les méta données. Elles sont complexes et demandent par conséquent beaucoup plus de temps. Ainsi, le temps de réponse limite est de 600 secondes, soit 10 minutes. Un exemple de requête dans cette catégorie est: “Donner le nombre des auteurs des ressources juridiques créees en 2016” (Voir Listing 2). Pour notre test, nous avons 24 requêtes de cette classe.

Listing 2 – Exemple de requête analytique

prefix cdm:
SELECT (COUNT(*) AS ?count) where{
select distinct ?lr ?author
where {
?lr cdm:work_created_by_agent ?author.
?lr cdm:work_date_creation_legacy ?dat_cre.
?lr a cdm:resource_legal .
FILTER (!regex(str(?dat_cre), "^2016-"))
}
}

Configuration du Benchmark

Il est possible de configurer le bench en fonction de plusieurs paramètres, comme celles consistant à mettre le serveur dans les conditions de PROD (warm-up), du nombre de fois que l’on souhaite répéter une requête pour prendre la moyenne du temps de réponse, sans oublier de bien fixer le temps de réponse (time out).  Nous avons donc choisi pour chaque classe de requête la configuration suivante: Un warm-up de 20 fois le nombre de requête par catégorie, et on lancera 5 fois chaque requête pour prendre la moyenne des résultats.

Pour ce test, nous avons configuré un warm-up de 20 fois le nombre de requête par catégorie, et on lancera 5 fois après le “chauffage du serveur” chaque requête pour prendre la moyenne des résultats.

Résultats

Nous avons donc pu obtenir des résultats en fonction de notre configuration du benchmark.

    1. Temps moyen pour les requêtes instantanées: Nous remarquons (cf. tableau ci-dessous) que 9 requêtes ont un temps supérieur à la limite demandée (60s). Il s’agit des requêtes avec identifiants Q5-Q10, Q12, Q14 et Q17. Ce qui donne juste 45% de réussite avec Neptune, si celle-ci se mésure par le nombre de requête avec temps inférieur à 60s.
      Requête Temps (seconde)
      Q1 0,042s
      Q2 0,052s
      Q3 0,085s
      Q4 0,121s
      Q5 >60s
      Q6 >60s
      Q7 >60s
      Q8 >60s
      Q9 >60s
      Q10 >60s
      Q11 0,119s
      Q12 >60s
      Q13 0,086s
      Q14 >60s
      Q15 0,08s
      Q16 0,094s
      Q17 >60s
      Q18 0,205s
      Q19 0,138s
      Q20 0,087s
    2. Temps moyen pour les requêtes analytiques. Ici, on a des bien bonnes nouvelles, comme l’indique le tableau ci-dessous. Nous avons un taux de 100% de réussite (pas de réponse supérieure à 600s).
      Requête Temps (seconde)
      Q1 15,94s
      Q2 36,12s
      Q3 56,62s
      Q4 1,08s
      Q5 63,71s
      Q6 1,12s
      Q7 0,04s
      Q8 0,84s
      Q9 0,06s
      Q10 25,80s
      Q11 0,97s
      Q12 28,16s
      Q13 0,24s
      Q14 120,36s
      Q15 14,01s
      Q16 5,24s
      Q17 2,63s
      Q18 12,89s
      Q19 5,23s
      Q20 2,60s
      Q21 17,78s
      Q22 5,36s
      Q23 2,77s
      Q24 3,04s
  1. Les tests peuvent continuer pour savoir par exemple les temps de réponses en cas de simulations de plusieurs requêtes en parallèle pour voir la robustesse de la base. Nous laisserons ce test pour les plus curieux 🙂

    AWS Neptune, tel que vu dans notre scénario n’est pas encore une Lamborghini mais en tout cas, n’est pas non plus une R4. Avec un bien mauvais taux de réussite pour les requêtes instantanées, Neptune a repris un sérieux avantage pour les requêtes analytiques. Nous espérons que le moteur est en cours de perfectionnement ou encore que des bonnes pratiques vont sortir pour aider à mieux adapter les requêtes SPARQL au moteur Neptune.

    Ghislain A.

1 Comment

Submit a Comment

Your email address will not be published. Required fields are marked *