Le Post Infeeny

Les articles des consultants et experts Infeeny

[JSS 2013] Session : SSAS : Test de montée en charge avec Visual Studio

Speaker : Arnaud Voisin
Level : 300-400

Cette session a pour but de nous montrer comment réaliser des tests de montée en charge sur Visual Studio.

Pourquoi en réaliser ?
Pour valider les exigences de performance de la solution, que ce soit l’architecture, le design, l’usage de l’application ou encore la qualité du code.

La session a été découpée en 4 parties :

  1. Déploiement de projets SSAS
  2. Stress tests
  3. Méthodologie des tests de performance
  4. Architecture de test

1/ Déploiement de projets SSAS

Dans cette partie, on va voir qu’il faut être vigilant sur certains points avant le déploiement d’un projet SSAS :

  • Meilleure optimisation SSAS sur les schémas en étoile
  • Parent child : il faut limiter les agrégations et ne les faire que sur les attributs clés, dans le meilleur des cas
  • Distinct count : créer une clé de partitionnement
  • Stockage : ne pas avoir des partitions trop petites (< 200Mo) ou trop grosses (> 3Go)

2/ Stress tests

Voici une liste de pré-requis avant de pouvoir réaliser les stress tests. Il faut avoir :

  • ASQueryPlan (outil de génération de Workload)
  • ASLoadSim (injecteur de charge)
  • Visual Studio Ultimate (Team System)
  • SQL Server
  • Solution SSAS OLAP / Tabular

Il faut aussi choisir son Workload (un Report RS, Excel, Power Pivot, …) et le variabiliser avec ASQueryPlan.

>> DEMO : Workload + Variabilisation

  • Il faut commencer par ouvrir SQL Profiler pour superviser les traitements qui seront lancés. Ensuite, à l’aide d’un refresh sur un fichier Excel, on regarde ce qui remonte dans SQL Profiler
  • Avec l’aide de ASLoadSim, on va pouvoir récupérer les requêtes qui ont été variabilisées dans l’ASQueryPlan >> C’est du code C#

3/ Méthodologie des tests de performance

On commence par définir nos objectifs/cas de test et la longueur des stress tests dont la formule est :

(Nb requêtes/fichiers) * nb fichiers * (tps de réponse estimé + thinktime (??)) Il faut ensuite choisir le modèle de charge voulu (par étape, en fonction des objectifs ou constant). On peut mixer différents tests. Enfin, on choisit les compteurs à monitorer (CPU, I/O, mémoire, requêtes).

>> DEMO : Run d’un load test

Pour cette démo, il nous a montré son code et l’a exécuté. Vous pouvez voir un résultat ci-dessous :

4/ Architecture de test

  • ASLoadSim est monobase c’est-à-dire qu’il ne peut être associé qu’à un cube. Il est possible de le lancer sur plusieurs cubes mais il faudra le dupliquer autant de fois qu’il y a de cube.
  • Architecture controleur-agent : il est conseillé d’avoir un CPU utilisé inférieur à 70% et une RAM supérieure à 10%.
  • Les tests de montée en charge peuvent être dispo sur le cloud via Visual Studio Online. Il faut néanmoins mettre à disposition les fichiers de Workload, le cube et les fichiers de conf associés.

Conclusion :

Les tests de montée en charge se font grâce à Visual Studio. On utilise le provider ADOMDNet pour les cubes MultiDim et Tabular (MDX, DMX et DAX), et d’autres providers pour du SAP, Oracle.
Session assez technique.

David – Consultant décisionnel MCNEXT

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :