Conseils de planification de la capacité pour Power BI Report Server

Power BI Report Server est une solution de création de rapports en libre-service et de création de rapports d’entreprise que les clients peuvent déployer localement, derrière leur pare-feu. Il combine la fonctionnalité de rapport interactive de Power BI Desktop avec la plateforme de serveur locale de SQL Server Reporting Services. Avec une utilisation intensive et croissante de l’analytique et de la création de rapports au sein des entreprises, le budget de l’infrastructure matérielle et des licences logicielles nécessaires à la mise à l’échelle vers une base d’utilisateurs d’entreprise peut être un défi. Ce document propose des conseils sur la planification de la capacité de Power BI Report Server en partageant les résultats de plusieurs exécutions de test de charge de différentes charges de travail exécutées sur un serveur de rapports. Bien que les rapports, les requêtes et les modèles d’utilisation des organisations varient largement, les résultats présentés dans ce document, ainsi que les tests réels utilisés et une description détaillée de la façon dont ils ont été exécutés, servent de point de référence pour toute personne dans le processus de planification précoce du déploiement de Power BI Report Server.

Synthèse

Nous avons exécuté deux types de charges de travail différents sur Power BI Report Server ; chaque charge de travail consiste à restituer différents types de rapports, ainsi qu’à effectuer différentes opérations de portail web.

• Dans la charge de travail « Power BI Report Heavy », l’opération la plus fréquemment exécutée (c’est-à-dire l’opération exécutée 60% du temps) a rendu des rapports Power BI.
• Dans la charge de travail « Rapport paginé lourd », l’opération la plus fréquemment exécutée a rendu des rapports paginés.

Sous une topologie à quatre serveurs de Power BI Report Server et l’attente que pas plus de 5% d’utilisateurs accèdent à un serveur de rapports à tout moment, le tableau suivant décrit le nombre maximal d’utilisateurs que Power BI Report Server peut gérer avec au moins 99% fiabilité.

Dans chaque exécution, la ressource la plus submergée était le processeur. En raison de cela, l’augmentation du nombre de cœurs vers Power BI Report Server génère un gain plus élevé dans la fiabilité du système que l’augmentation de la quantité d’espace mémoire ou disque dur.

Méthodologie de test

La topologie de test utilisée était basée sur des machines virtuelles Microsoft Azure plutôt que sur du matériel physique spécifique au fournisseur. Toutes les machines ont été hébergées dans les régions américaines. Cela reflète la tendance générale de la virtualisation matérielle locale et dans le cloud public.

Topologie Power BI Report Server

Le déploiement de Power BI Report Server se compose des machines virtuelles suivantes :

• Contrôleur de domaine Active Directory : cela a été nécessaire par le moteur de base de données SQL Server, SQL Server Analysis Services et Power BI Report Server pour authentifier en toute sécurité toutes les requêtes.
• Moteur de base de données SQL Server et SQL Server Analysis Services : c’est là que nous avons stocké toutes les bases de données des rapports à consommer lorsque nous les avons rendues.
• Serveur de rapports Power BI
• Base de données Power BI Report Server. La base de données du serveur de rapports est hébergée sur un ordinateur différent de Power BI Report Server afin qu’elle n’ait pas besoin de concurrencer le moteur de base de données SQL Server pour la mémoire, le processeur, le réseau et les ressources de disque.

Consultez l’annexe 1.1 Topologie power BI Report Server et l’annexe 1.2 Configuration de machine virtuelle Power BI Report Server pour une configuration complète de chaque machine virtuelle utilisée dans la topologie.

Épreuves

Les tests utilisés dans les exécutions de test de charge sont publiquement disponibles dans un projet GitHub appelé LoadTest de Reporting Services. Cet outil permet aux utilisateurs d’étudier les caractéristiques de performances, de fiabilité, d’extensibilité et de récupération de SQL Server Reporting Services et power BI Report Server. Ce projet se compose de quatre groupes de cas de test :

• Test simulant le rendu des rapports Power BI,
• Test simulant le rendu des rapports mobiles,
• Teste la simulation du rendu de rapports paginés petits et volumineux, et
• Teste la simulation d’exécution de différents types d’opérations de portail web.

Tous les tests ont été écrits pour effectuer une opération de bout en bout (comme le rendu d’un rapport, la création d’une source de données, etc.). Pour ce faire, effectuez une ou plusieurs requêtes web sur le serveur de rapports (via des API). Dans le monde réel, un utilisateur peut avoir besoin d’effectuer quelques opérations intermédiaires pour effectuer l’une de ces opérations de bout en bout. Par exemple, pour afficher un rapport, un utilisateur doit accéder au portail web, accéder au dossier où se trouve le rapport, puis cliquer sur le rapport pour le rendre. Bien que les tests n’effectuent pas toutes les opérations nécessaires pour accomplir une tâche de bout en bout, ils imposent toujours la majeure partie de la charge que Power BI Report Server rencontrerait. Vous pouvez en savoir plus sur les différents types de rapports utilisés ainsi que sur la variété des opérations effectuées en explorant le projet GitHub.

Workloads

Il existe 2 profils de charge de travail utilisés dans les tests : Power BI Report Heavy et Paginated Report Heavy. Le tableau ci-dessous décrit la distribution des requêtes exécutées sur le serveur de rapports.

Charge utilisateur

Pour chaque série de tests, les tests ont été exécutés en fonction de la fréquence spécifiée dans l’une des deux charges de travail. Les tests ont démarré avec 20 demandes utilisateur simultanées sur le serveur de rapports. La charge de l’utilisateur a ensuite été progressivement augmentée jusqu’à ce que la fiabilité soit tombée sous la cible de 99%.

Results

Capacité utilisateur simultanée

Comme indiqué précédemment, les tests ont commencé avec 20 utilisateurs simultanés qui effectuent des demandes au serveur de rapports. Le nombre d’utilisateurs simultanés a ensuite été progressivement augmenté jusqu’à ce que 1% de toutes les demandes échouent. Le tableau suivant indique le nombre de requêtes utilisateur simultanées que le serveur serait en mesure de gérer en cas de pic de charge avec un taux d’échec inférieur à 1%.

Capacité totale de l’utilisateur

Chez Microsoft, nous avons un déploiement de production de Power BI Report Server que plusieurs équipes ont utilisées. Lorsque nous analysons l’utilisation réelle de cet environnement, nous observons que le nombre d’utilisateurs simultanés à un moment donné (même pendant les pics de charge quotidienne) n’a pas tendance à dépasser 5% de la base d’utilisateurs totale. À l’aide de ce taux de concurrence de 5% comme benchmark, nous avons extrapolé le nombre total d'utilisateurs que Power BI Report Server pourrait gérer avec une fiabilité de 99%.

Résumé

Pour chaque exécution de test de charge, le CPU était la ressource la plus sollicitée au moment du pic de charge sur le serveur Power BI Report. En raison de cela, la première ressource qui doit être augmentée est le nombre de cœurs. Vous pouvez également envisager un scale-out en ajoutant d’autres serveurs hébergeant Power BI Report Server dans votre topologie.

Les résultats présentés dans ce document ont été dérivés de l’exécution d’un ensemble spécifique de rapports consommant un ensemble spécifique de données, répété d’une manière spécifique. Il s’agit d’un point de référence utile, mais gardez à l’esprit que votre utilisation dépend de vos rapports, requêtes, modèles d’utilisation et déploiement de votre serveur de rapports Power BI.

Appendice

1 Topologie

1.1 Topologie Power BI Report Server

Pour se concentrer uniquement sur le comportement de Power BI Report Server sous différentes configurations, la configuration de machine virtuelle pour chaque type de machine (à l’exception de la machine hébergeant Power BI Report Server) a été corrigée. Chaque machine a été provisionnée en fonction des machines de la série D de seconde génération (v2) avec des disques de stockage Premium. Vous trouverez des informations détaillées sur chaque taille de machine virtuelle sous la section « Usage général ».

1.2 Configuration de machine virtuelle Power BI Report Server

Différentes configurations de processeur et de mémoire ont été utilisées pour la machine virtuelle hébergeant Power BI Report Server. Contrairement aux autres machines virtuelles, cette machine a été approvisionnée en fonction des machines de série D de troisième génération (v3) avec des disques de stockage Premium. Vous trouverez des informations détaillées sur cette taille de machine virtuelle dans la section « Usage général »

2 Exécuter l’outil LoadTest

Si vous souhaitez exécuter l’outil LoadTest Reporting Services sur votre déploiement Microsoft Azure de Power BI Report Server, procédez comme suit.

1. Clonez le projet LoadTest Reporting Services à partir de GitHub (https://github.com/Microsoft/Reporting-Services-LoadTest).
2. Dans le répertoire du projet, vous trouverez un fichier solution appelé RSLoadTests.sln. Ouvrez ce fichier dans Visual Studio 2015 ou version ultérieure.
3. Déterminez si vous souhaitez exécuter cet outil sur votre déploiement de Power BI Report Server ou sur un déploiement de Power BI Report Server dans Microsoft Azure. Si vous allez l’exécuter sur votre propre déploiement, passez à l’étape 5.
4. Suivez les instructions listées sur https://github.com/Microsoft/Reporting-Services-LoadTest#create-a-sql-server-reporting-services-load-environment-in-azure pour créer un environnement Power BI Report Server dans Azure.
5. Une fois que vous avez terminé le déploiement de l’environnement, suivez les instructions listées sur https://github.com/Microsoft/Reporting-Services-LoadTest#load-test-execution pour exécuter les tests.

Plus de questions ? Essayez d’interroger la communauté Power BI