Introduction

Suite à la release 1.2.0 de MRules, où de nombreuses optimisations internes ont été mises en place et où des fonctionnalités clés ont été ajoutées (telles que l’accès strict aux méthodes ou champs des objets), nous avons décidé de réaliser un benchmark de notre produit, en le comparant à ce qui existe sur le marché.

L’adversaire est de taille : il s’agit de Drools, le leader Open Source des moteurs de règles. Basée sur l’algorithme RETE, cette librairie a la réputation d’offrir d’excellentes performances.

Pour ce test, un cas métier fictif mais crédible a été inventé, le modèle objet a été implémenté, les règles écrites ainsi que des jeux de données.

Description du cas métier

Nous avons imaginé le cas d’un laboratoire analysant la qualité de l’air. Ce laboratoire reçoit donc régulièrement des rapports de mesures, chaque mesure étant composée de plusieurs prélèvements et concernant un ou plusieurs composant(s) polluant(s).

A la réception d’une mesure, la cohérence des données est vérifiée, selon des règles métier. Cette vérification occasionne potentiellement la génération d’une ou plusieurs erreurs, bloquantes ou non.

Après validation, si aucune erreur bloquante, un indice de qualité de l’air est donné.

Description des données

Une mesure est constituée des données suivantes :

• Des dates de début et de fin
• Une localisation
• Des contacts (mails)
• Un nombre de prélèvements
• La fréquence des prélèvements (Minute, Heure, Jour)
• Des données sur les prélèvements, sous forme de Map (association clé / valeur) :
  • Clé : Type de polluant
  • Valeur : Objet Java contenant le type de polluant et la valeur de la mesure.

La modélisation de cette dernière donnée permettait de complexifier le modèle afin de tester les possibilités des produits et les possibilités de configuration offertes.

Les erreurs sont représentées sous la forme d’un Objet Java :

• Code de la règle
• Message d’erreur
• Bloquant ou non

Description des règles

Les règles sont les suivantes :

Code « DatesOk » :

• Les dates de début et de fin doivent être renseignées (Bloquant).
• La date de fin ne doit pas être antérieure à la date de début (Bloquant).

Code « LocationOk » :

• La localisation doit être renseignée (Bloquant).

Code « ContactsOk » :

• Au moins un contact est présent (Non Bloquant).
• Les contacts doivent être des emails valides. Vérification par expression régulière (Non Bloquant).

Code « SamplesOk » :

• Au moins 1 prélèvement et au maximum 10 (Bloquant).
• La fréquence doit être renseignée et valide (parmi M, H, D) (Bloquant).
• Au moins un polluant mesuré et au maximum (Bloquant).
• Le type de polluant doit être connu (i.e. présent dans des données de référence non connues des règles) (Bloquant).

Finalisation :

Règles écrivant les données de sortie :

• Valuation d’un champ contenant le nombre d’erreurs bloquantes.
• Puis si pas d’erreur bloquante :
  • Si au moins 1 polluant mesuré au delà du seuil 0.02 : Qualité de l’air mauvaise (« BAD »).
  • Si au moins 1 polluant mesuré au delà du seuil 0.01 : Qualité de l’air moyenne (« MEDIUM »).
  • Sinon : Qualité de l’air bonne (« GOOD »).

Jeux de test

16 jeux de données ont été créés, certains avec une ou plusieurs erreur(s), d’autres non. L’objectif étant de tester l’intégralité des règles définies.

Implémentation du test

Le benchmark a été écrit sous la forme d’un module Maven et de tests JUnit.

3 TU Junit ont été écrits :

• Un test mettant en œuvre des règles écrites en Java natif.
• Un test mettant en œuvre Drools.
• Un test mettant en œuvre MRules.

La configuration de Drools a été faite en utilisant le langage DRL. En effet, l’utilisation des tables de décision en format Excel a été tentée mais certaines règles n’ont jamais fonctionné par ce moyen.

Voici la configuration finale en DRL.

La configuration MRules a elle été écrite en XML.

Le code source complet du benchmark peut également être téléchargée (une licence valide est nécessaire).

Résultats du test

L’objectif de ce bench est de comparer trois points principaux :

• L’intégration.
• La facilité de la configuration.
• Les performances, calculées sur un poste standard pour 1 compilation et 10 000 exécutions des 16 cas. Pour MRules, les tests ont été lancés en compilation standard et light

* Les chiffres varieront d’un ordinateur à l’autre selon la puissance de calcul disponible. Les proportions sont ici la donnée intéressante.

Interprétation

Au niveau de l’intégration

Les librairies sont similaires : peu de dépendances et peu de code Java à écrire. Il est facile de créer un utilitaire centralisant la gestion des utilisations de moteurs de règles. Drools a cependant plus de dépendances transitives et est donc plus gourmand en espace.

Concernant la configuration

Avec l’implémentation native Java, toutes les options sont disponibles, selon le budget.

Avec Drools, en utilisant le langage DRL, on peut déplorer de remplacer du code … par du code. De plus, Drools ne tenant pas compte de l’ordre des règles dans le fichier pour leur exécution, il est nécessaire d’ajouter des instructions spécifiques pour rafraichir les données ou afin d’éviter les boucles infinies.
Un intervenant non technique motivé sera à même de modifier certaines valeurs de seuil, mais certainement pas de modifier le comportement.

Avec MRules, le langage XML permet une écriture plus mécanique et encadrée des règles.
Un intervenant non technique pourra en comprendre le fonctionnement, modifier les valeurs de seuil et modifier certains comportements. Il est certain qu’une modification en profondeur nécessitera un support de l’équipe technique.

(A noter que nous travaillons actuellement sur d’autres formats de configuration – Excel, texte – permettant de s’adapter à tout type d’utilisateurs finaux)

Pour les performances

Ici, les résultats bruts parlent d’eux mêmes.

L’implémentation Java est plus rapide pour ce type de règles, c’est-à-dire séquentielles, peu nombreuses, avec peu ou pas d’algorithmique et fortement orientées business. En effet, aucune couche d’abstraction n’est présente et n’occasionne un surcoût machine.

Par contre, nos efforts en termes de conception et d’optimisation pour les cas d’utilisation visés sont payants. Sur ce créneau et ce type de métier, notre moteur est nettement supérieur à Drools en termes de performances, que ce soit en phase de compilation ou d’exécution.

Nous travaillons également pour les futures versions sur de nouveaux algorithmes et optimisations, dans le but de nous rapprocher du temps de référence de l’implémentation Java… voire même en deçà.