Nous avons réalisé pour un de nos clients souhaitant déployer la BI 4.2 à plus de 3500 utilisateurs dont 300 en simultané, un Stress Test de la plateforme SAP BusinessObjects.
Qu’est ce qu’un Stress Test ?
Une épreuve d’effort (stress test ou test de performance), est une opération qui sert à déterminer la stabilité d’un système ou d’une architecture.
Dans notre cas, l’objectif est de simuler l’utilisation d’une plateforme SAP BusinessObjects BI 4.2 par 300 utilisateurs simultanément.
Quel est notre but ?
- Tester les performances de SAP BusinessObjects lorsque la plateforme est soumise à une forte utilisation
- Valider la fiabilité de l’architecture technique mise en place
- Définir les temps de réponses moyens
Nous avons simulé dans ce stress test, les actions les plus courantes effectuées par les utilisateurs d’un système SAP BusinessObjects :
- Connexion à la plateforme en mode Web
- Ouverture d’un document Web Intelligence
- Rafraichissement des données du document
- Fermeture du document
- Déconnexion
Pour réaliser ce test, nous avons choisi d’utiliser le produit « JMeter ». Celui-ci nous permet de créer un scénario, composé de N actions. Pour préparer ce test, nous avons enregistré l’activité d’un utilisateur BO de type « Lecteur » (Connexion, Ouverture d’un document, Rafraichissement, …).
Une fois ce scénario réalisé, nous avons pu le jouer simultanément, jusqu’à 300 fois, sur notre plateforme BO.
Définition du plan de test
Les scénarios de tests suivants ont été exécutés sur la plateforme :
Ce scénario a été répété 3 fois. Ceci permet de calculer une moyenne et de vérifier qu’un élément parasite ne vienne pas polluer notre test.
Grâce à ce test, nous avons pu analyser l’évolution des temps de réponse de la plateforme, en fonction du nombre d’utilisateurs qui effectuent une action sur la plateforme.
Architecture de notre plateforme BI
Notre plateforme BI est composée d’un serveur BO en version 4.2 SP3 Patch 2. Les composants Web (Tomcat) et Applicatifs (SIA) sont installés sur la même machine.
Notre serveur est virtualisé et possède un CPU 8 cœurs et 32 Go de RAM.
L’application BO est installée sur un système Windows 2012.
Choix du document à utiliser dans notre test
Afin de pouvoir tracer une courbe d’évolution des temps de réponse, nos différents scénarios doivent exécuter le même document. Ceci permettra de créer un point de référence et de voir évoluer les temps de réponse de la plateforme au fur et à mesure de la montée en charge. Le document sélectionné s’exécute en 5 secondes et affiche une centaine de lignes. Il a été choisi pour ne pas rencontrer les limitations présentées ci-dessous :
- Limitation liée à la base de données. Si le document exécute une requête SQL trop complexe ou ramène trop de lignes, nous pourrions arriver à une saturation du serveur de base de données et ceci impacterait nos mesures.
- Limite matérielle du disque dur hébergeant le document. Il y a un risque que certains processus soient en attente d’accès au fichier. Pour éviter ceci, le document de référence a été dupliqué 10 fois à l’identique. Ainsi, tous les utilisateurs virtuels accèdent au même document mais stocké à 10 endroits différents.
Rapport de test consolidé
L’outil « JMeter » permet de voir les résultats consolidés du plan de test, et permet de les sauvegarder dans un fichier CSV.
Dans ce rapport, nous avons analysé les indicateurs suivants :
- Temps moyen d’ouverture du document
- Temps moyen d’actualisation du document
- Temps moyen d’un cycle
- Temps total du plan de test
- % d’erreurs de connexions \ échec de connexion
Nous avons constaté que le taux moyen d’erreur de connexions est presque à 50% lorsque la plateforme BO est surchargée. 1 utilisateur sur 2 ne peut pas se connecter à la plateforme dès qu’il y a plus de 60 personnes déjà connectées.
Nous avons aussi constaté dans ces résultats que le temps de rafraichissement de référence (environ 5 secondes), est 5 fois plus important (environ 25 secondes) lorsque la plateforme est surchargée.
Il en est de même pour le temps total d’un cycle (connexion, ouverture, rafraichissement, fermeture et déconnexion), il faut environs 12 secondes à un utilisateur pour effectuer toutes ces actions, et il faut en moyenne 121 secondes à un utilisateur pour effectuer ces mêmes actions lorsque la plateforme est surchargée, soit 10 fois plus de temps.
CONCLUSION DE L’EXPERT
Avec notre serveur Virtuel BI 4.2 SP2 possédant 8 cœurs et 32 Go de RAM, nos tests de montée en charge nous ont montré que 60 utilisateurs simultanés peuvent utiliser notre plateforme. En effet, les performances et les erreurs de notre serveur BO commencent à se dégrader lorsque plus de 60 utilisateurs sont connectés simultanément sur la plateforme.
Les graphes ci-dessous nous ont montré une augmentation significative du nombre d’échec de connexion lorsque plus de 60 utilisateurs sont connectés à la plateforme.
Courbe d’évolution du taux d’échec de connexion
De plus, les indicateurs de temps de réponse nous montrent que dans un cycle d’utilisation, le temps de rafraichissement du document ainsi que le temps total d’un cycle d’utilisation vont augmenter lors d’une forte utilisation de la plateforme.
Courbe d’évolution du temps de rafraichissement
Dans notre contexte de départ, afin d’assurer un service optimal à 300 utilisateurs en simultané, cette plateforme ne peut suffire. Elle conviendrait à un déploiement pour 60 utilisateurs simultanés mais pas 300.
Nous avons donc préconisé à notre client de mettre en place un cluster de 5 serveurs BO (chaque serveur possédant 8 cœurs et 32 Go de RAM), permettant de gérer en parallèle 5 fois 60 utilisateurs, soit 300 utilisateurs simultanément.
