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 :
- L’utilisateur s’authentifie
- Il accède à l’espace racine d’Alfresco (My Alfresco ou Repository)
- Il accède à l’espace de test racine, contenant les 10 espaces de tests.
- 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.
Accueil du blog
