Alfresco : audit de performances d’Explorer vs Share

Alfresco Share, étant plus récent qu’Alfresco Explorer, bénéficie de nouvelles améliorations et c’est bien normal. Mais au delà des nouveautés fonctionnelles, qu’en est-il des performances ? C’est ce que StarXpert a cherché à savoir en effectuant un audit des deux interfaces.

StarXpert a donc mis face à face Alfresco Explorer, l’interface développée en JSF, et Alfresco Share, l’interface développée avec le nouveau framework Spring Surf. StarXpert a utilisé JMeter pour stresser l’application, et a étudié le comportement de la machine pendant les phases de tests grâce à des outils développés en interne.

Méthodologie

La version installée est Alfresco Enterprise 3.4. Un script JMeter a été développé pour stresser l’interface Explorer. Puis, un script équivalent a été développé pour l’interface Share. Ces scripts sont simples : Ils se contentent de parcourir une dizaine d’espaces contenant entre 4 et 866 fichiers pdf (pour un total de 2 319 fichiers). Le scénario est le suivant :

  1. L’utilisateur s’authentifie
  2. Il accède à l’espace racine d’Alfresco (My Alfresco ou Repository)
  3. Il accède à l’espace de test racine, contenant les 10 espaces de tests.
  4. Il rentre dans un espace de test et liste les fichiers.

Les étapes 3 et 4 sont répétées en boucle jusqu’à la fin du test. Le script changeant d’espace à chaque itération, au total 1000 itérations sont effectuées pour chaque test.

Le test a été lancé successivement avec 5, 10, 15, 20, 25, 30, 35, 40, 45 et 50 threads simultanés. Il faut préciser qu’un thread ne correspond pas à un utilisateur réel. On peut considérer qu’un thread impact le serveur de la même façon que 5 à 10 utilisateurs travaillant simultanément.

Le serveur utilisé pour ce test est un serveur virtualisé sur vmware avec 2 cpu et 4Go de RAM, application sur Tomcat et MySQL.

Résultat

Les deux graphiques ci-dessous présentent une synthèse des résultats pour les deux interfaces.

Les barres représentent le temps de réponse moyen d’une page en millisecondes. Le premier trait pointillé correspond à 1 seconde, le premier trait plein correspond à 2 secondes.

Les lignes représentent le débit moyen en pages par minutes. L’échelle utilisée ici est exponentielle, en moyenne le débit est compris entre 300 et 1100 pages par minutes.

On constate que l’interface Explorer s’effondre lorsque la charge est trop importante (>35 threads) alors que l’interface Share encaisse la charge de façon linéaire.

On peut voir aussi que le débit maximal de la machine (~1k pages/minutes) est atteint avec 15 threads, soit 75 à 150 utilisateurs. Au dessus de ce seuil, les performances vont naturellement se dégrader.

Cependant, le point le plus important de l’étude est de constater qu’après les tests de charge, le système se rétablit parfaitement si on utilise l’interface Share, ce qui n’est pas le cas pour l’interface Explorer. Un redémarrage de l’environnement Tomcat devient indispensable !

Ceci s’explique en regardant l’évolution de la mémoire JAVA. La région Old Generation de la pile mémoire se remplit progressivement au cours des tests, jusqu’à atteindre le seuil maximal. Ceci provoque un déclenchement disproportionné du Garbage Collector et impact très fortement les performances.

En utilisant l’interface Share, ce phénomène ne se rencontre pas.

Conclusion

Cette étude nous montre que l’interface Share gère mieux la mémoire Java que l’interface Explorer. Elle peut donc plus facilement subir un pic d’activité sans compromettre la stabilité de l’application. On peut conclure également que l’usage d’outils de stress et de supervision (tels que ceux développés par StarXpert) est necessaire pour mieux calibrer et optimiser les serveurs Alfresco.

 

Alfresco Share : StarXpert dévoile un nouveau module d’audit

Alfresco Share Usage Reporting est un module Alfresco Share basé sur le système d’audit d’Alfresco, il permet de définir et de visualiser les différentes statistiques de l’utilisation du serveur GED Alfresco.

ASUR est accessible depuis la console d’administration Share. Il affiche sous forme de graphe les statistiques courantes de l’utilisation d’Alfresco (Nombre de hits, nombre et volume des fichiers créés/supprimés, Workflows démarrés… ) sur une période donnée, et permet leur impression à la demande.

La période d’audit est définie par l’utilisateur et l’affichage est cumulé par heure, jour ou mois.

L’un des points forts d’ASUR est qu’il permet de filtrer les fonctionnalités de reporting par utilisateur (excepté le « nombre de connexions uniques », lequel visualise le nombre d’utilisateurs uniques qui se sont connectés dans une période donnée et ne dépend donc pas d’un seul utilisateur).
De plus, de par sa nature de module Alfresco (Alfresco Module Package), ASUR est facile à installer. Son utilisation est intuitive grâce a une interface simple et épurée.

Dans un but de vision globale, ASUR peut cumuler deux fonctionnalités d’audit compatibles dans un même graphe. Par exemple : fichiers crées/supprimés, workflows démarrés/terminés.

La liste des données auditées est la suivante :

  • Nombre de hits
  • Nombre de connexions uniques
  • Nombre de Fichiers créés
  • Nombre de Fichiers supprimés
  • Nombre de fichiers Créés/Supprimés
  • Nombre de fichiers téléchargés
  • Volume des fichiers téléchargés
  • Workflows démarrés
  • Workflows terminés
  • Workflows démarrés/terminés

Télécharger ASUR (licence LGPL)

ASUR est téléchargeable depuis la forge Alfresco

En savoir plus sur Alfresco Share

Démonstration de la Gestion Documentaire Alfresco

Comment effectuer un audit avec Alfresco 3.4 ?

Il y a bien des cas où il est utile de savoir quelles personnes ont pris connaissent d’un document. C’est pourquoi Alfresco comporte une fonction d’audit. Avec la version 3.4 d’Alfresco apparaît une nouvelle façon d’effectuer un audit. Si cette nouvelle méthode présente des avantages par rapport à l’ancienne, elle n’est pas sans impact sur l’historique des données héritées des anciennes versions d’Alfresco. Cet article se propose d’expliquer en quoi il est intéressant d’effectuer un audit, les différences notoires entre l’audit sous Alfresco 3.4 et les versions précédentes et enfin la manière d’exécuter un audit Alfresco.

Qu’est-ce que l’audit Alfresco ?

Mettre en place un audit sur une application permet d’en tirer des statistiques. Les données qui peuvent être auditées sont par exemple :

  • le nombre de connections à la journée, au mois, à l’année sur une période donnée.
  • le nombre de documents lus / modifiés / supprimés / ajoutés en une journée, un mois, une année, sur une période donnée.

Pour chacune des données auditées il peut être intéressant de croiser ces informations avec d’autres données afin d’obtenir des statistiques plus précises comme par exemple :

  • le nombre de connections à la journée, au mois, à l’année sur une période donnée pour un utilisateur particulier.
  • le nombre de documents lus / modifiés / supprimés / ajoutés en une journée, un mois, une année sur une période donnée par un utilisateur particulier.
  • le nombre de fois qu’un document spécifique a été lu / modifié par tel utilisateur.

Pour mettre en place un audit il faut obligatoirement définir une période d’audit, c’est à dire les dates qui vont définir les bornes de l’audit. Toutes les autres informations facultatives qui peuvent être définies pour l’audit permettent d’effectuer des statistiques suivant un contexte particulier (pour un utilisateur donné, pour un document donné, …).

Principe de l’audit avec Alfresco 3.4

Avec la version 3.4 d’Alfresco le système d’audit a changé. Il faut maintenant définir dans un fichier xml les actions que l’on souhaite auditer (connexions, lecture, …). De plus, un webscript permet maintenant de récupérer les résultats de l’audit au format JSON (un fichier JSON est un fichier texte qui permet de représenter de l’information structurée). Ce fichier doit ensuite être exploité par un autre langage (page php, html, …) pour extraire des résultats sous la forme d’un graphique, par exemple, car il n’existe pour l’instant pas d’interface permettant de lire les résultats de l’audit.

Dans le fichier xml il faut définir :

  • la méthode à auditer
  • les éléments à enregistrer au moment de l’exécution de l’action
  • les éléments à retourner lors de l’audit

Le webscript créé par Alfresco doit être appelé par l’url : http://<serveur-alfresco>:<port>/alfresco/service/api/audit/query/<applicationName>

  • <serveur-alfresco> : nom du serveur sur lequel est installé alfresco
  • <port> : port utilisé pour accéder à l’application
  • <applicationName> : nom de l’action auditée défini dans le fichier xml

Différences avec l’ancienne méthode d’audit

Pour mettre en place un audit en version 3.4, il n’est plus nécessaire de requêter la base de données directement. Cela présente l’avantage d’être indépendant par rapport aux couches basses du code, aussi l’audit continuera à fonctionner même si ces couches sont modifiées. Pour ajouter de nouvelles données dans les tables d’audit il suffit de configurer les fichiers xml, ce qui est plus simple et plus rapide qu’avec l’ancienne méthode, et ne nécessite plus d’avoir des connaissances en Hibernate.

Les tables utilisées pour l’audit ont changé et les anciennes tables d’audit ont été supprimées. Cela implique que les données auditées en version inférieure ne pourront pas être récupérées. Toutes les requêtes SQL utilisées dans l’ancien audit devront être remplacées par des appels à l’API fournis à travers les fichiers de configuration XML.

Exemple : Audit des connections

Pour mieux comprendre le fonctionnement de l’audit voici un petit exemple qui nous permettra d’auditer les connections à l’application.

Fichier xml : audit-authenticate.xml

<Audit xmlns="http://www.alfresco.org/repo/audit/model/3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.alfresco.org/repo/audit/model/3.2 alfresco-audit-3.2.xsd" >
    <DataExtractors>
        <DataExtractor name="simpleValue" registeredName="auditModel.extractor.simpleValue"/>
    </DataExtractors>
    <DataGenerators>
        <DataGenerator name="personFullName" registeredName="auditModel.generator.personFullName"/>
    </DataGenerators>
    <PathMappings>
        <PathMap source="/alfresco-api/post/AuthenticationService/authenticate" target="/auditExempleLogin/login"/>
    </PathMappings>
    <Application name="AuditExempleLogin" key="auditExempleLogin">
        <AuditPath key="login">
            <AuditPath key="args">
                <AuditPath key="userName">
                    <RecordValue key="userName" dataExtractor="simpleValue" />
                </AuditPath>
            </AuditPath>
            <AuditPath key="no-error">
                <GenerateValue key="fullName" dataGenerator="personFullName"/>
            </AuditPath>
        </AuditPath>
    </Application>
</Audit>

On choisit ici d’auditer la méthode d’authentification qui est définit dans la partie <PathMappings>. La partie <Application> permet de définir quels éléments seront audités. Dans cet exemple on veut connaître le login de la personne qui se connecte ainsi que les propriétés Nom et Prénom.

Un dataExtractor est un composant qui utilise les données d’entrée pour produire une sortie. L’extracteur le plus simple est le SimpleValueDataExtractor, qui retourne toutes les données transmises. Pour connaître le login on récupère l’argument username par la méthode authenticate grâce au dataExtractor simpleValue. Il est possible de créer ses propres extracteurs en développant une nouvelle classe qui étendra la classe AbstractDataExtractor.

Un dataGenerator est un composant qui produit des données sans entrée. Les exemples de générateurs sont les classes :

  • AuthenticatedUserDataGenerator qui produit le nom de l’utilisateur couramment authentifié
  • AuthenticatedPersonDataGenerator qui produit le nom complet de l’utilisateur actuellement authentifié

Pour retourner les propriétés Nom et Prénom on utilise le dataGenerator personFullName qui correspond à la classe AuthenticatedPersonDataGenerator. Tout comme les extracteurs il est possible de créer de nouveaux générateurs en développant une nouvelle classe qui étendra la classe AbstractDataGenerator.

Appel de l’audit

En exécutant le webscript correspondant à l’url http://<serveur-alfresco>:<port>/alfresco/service/api/audit/query/AuditExempleLogin?verbose=true on obtient un fichier JSON qui nous retourne les éléments suivants :

{
   "count":2,
   "entries":
   [
      {
         "id":1,
         "application":AuditExempleLogin,
         "user":admin,
         "time":"2011-02-24T14:30:36.698+01:00",
         "values":
         {
                     "/auditExempleLogin/login/no-error/fullName":"Administrator"
                     ,"/auditExempleLogin/login/args/userName/userName":"admin"
         }
      },
      {
         "id":2,
         "application":AuditExempleLogin,
         "user":cpiassale,
         "time":"2011-02-24T14:31:33.455+01:00",
         "values":
         {
                     "/auditExempleLogin/login/no-error/fullName":"Cindy PIASSALE"
                     ,"/auditExempleLogin/login/args/userName/userName":"cpiassale"
         }
      }
   ]
}

Dans cet exemple on peut voir qu’il y a eu deux personnes qui se sont connectées : admin et cpiassale. Dans la liste « values » on retrouve les éléments que l’on souhaitait connaître par le biais de l’audit :

  • « /auditExempleLogin/login/no-error/fullName » : nom et prénom de l’utilisateur connecté
  • « /auditExempleLogin/login/args/userName/userName » : login de la personne qui a déclenché la méthode d’authentification

Il existe un certain nombre de dataExtractor et de dataGenerator par défaut. Dans le cas où l’on souhaite auditer ses propres services et méthodes il est possible de développer de nouveaux dataExtractor ou dataGenerator pour récupérer les données recherchées.