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. 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

2. 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.