Résolution des problèmes de performances de rapport

Nouveau : 17 novembre 2008

Cette rubrique décrit différentes techniques permettant d'accroître les performances du rapport.

Pour résoudre les problèmes de performances de rapport, utilisez les fichiers journaux de Reporting Services pour déterminer la phase qui nécessite le plus de temps d'activité : l'extraction des données, le traitement de la disposition du rapport ou le rendu du rapport. Pour plus d'informations, consultez Dépannage des problèmes liés aux rapports.

Après cela, utilisez les sections suivantes pour vous aider à résoudre les problèmes spécifiques.

Amélioration des performances d'extraction de données

Amélioration des performances de traitement des rapports

Amélioration des performances de rendu des rapports

Amélioration des performances d'extraction de données

Une quantité de données de rapport plus importante utilise davantage de ressources et davantage de stockage, crée davantage de trafic réseau et requiert davantage de temps de traitement. Pour vous aider à contrôler les performances des rapports, vous devez vous efforcer de concevoir des rapports avec une quantité de données et une complexité raisonnables. Par exemple, peu d'utilisateurs souhaitent visualiser un rapport d'un millier de pages. Il est difficile de suivre le contexte pour un rapport d'extraction si la table contient trop de niveaux d'imbrication ou d'analyser une table avec un nombre de colonnes trop élevé. Les graphiques à secteurs qui contiennent des centaines de secteurs sont difficilement lisibles. Vous devez analyser soigneusement les spécifications de vos rapports afin de déterminer la quantité de données nécessaire, puis extraire uniquement ces données à partir des sources de données de rapport.

Utilisez les informations des sections suivantes pour vous aider à réduire la durée nécessaire à l'extraction des données pour votre rapport.

Extraction d'une quantité de données supérieure aux besoins réels

Il est plus efficace de filtrer, trier et agréger de grandes quantités de données sur la source de données plutôt que durant le traitement du rapport. Écrivez les requêtes de façon à retourner uniquement les données que vous souhaitez afficher dans le rapport. Si vous prévoyez d'afficher uniquement un résumé des données, calculez les valeurs agrégées sur la source de données et n'extrayez pas les données détaillées. La liste suivante contient quelques suggestions pour l'évaluation de chaque requête de rapport dans le rapport :

• Écrivez des requêtes avec des clauses WHERE ou HAVING de manière à limiter les données uniquement à ce que l'utilisateur doit visualiser dans le rapport. Utilisez des paramètres de requêtes pour limiter les données extraites au moment de l'exécution. Pour plus d'informations, consultez Filtrage des lignes avec les clauses WHERE et HAVING.
  Lorsque vous créez un rapport instantané avec des paramètres de rapport qui filtrent les données, toutes les données qui peuvent être affichées dans le rapport doivent être enregistrées dans la capture instantanée. Dans ce cas, n'utilisez pas de paramètres de requêtes dans les requêtes de dataset. Au lieu de cela, créez manuellement des paramètres de rapport que vous pouvez utiliser dans des expressions de filtre afin de permettre aux utilisateurs de spécifier les données du rapport souhaitées.
• Écrivez des requêtes avec la clause ORDER BY afin d'effectuer un tri préalable des données extraites pour un rapport. Triez les données dans l'ordre dans lequel vous souhaitez qu'elles soient triées dans le rapport. Le tri préalable des données améliore la durée de traitement du rapport grâce à la manière dont elles sont stockées en mémoire. Pour de nombreuses tâches de traitement de rapport, il n'est pas nécessaire de trier les données avant de les traiter. Par exemple, SUM ne dépend pas de l'ordre de tri. Les données dans les instances de groupes ne sont pas triées automatiquement. Si vous n'avez pas besoin de trier les données dans le rapport, n'utilisez pas d'expressions de tri sur le dataset ou la région de données. Pour plus d'informations, consultez Clause ORDER BY (Transact-SQL) et Tri des données dans un rapport.
  Toutefois, le tri des groupes ou le tri par valeurs agrégées est plus simple à effectuer dans le rapport que dans la requête. Il est souvent plus efficace de trier les groupes dans le rapport plutôt que dans la requête.
• Écrivez des requêtes avec la clause GROUP BY pour agréger les valeurs sur la source de données
  Bien souvent, le moyen le plus efficace de communiquer des informations consiste à agréger des valeurs et à afficher des résumés. Vous pouvez calculer certains niveaux d'agrégation sur la source de données et les extraire pour un dataset. Les données « détaillées » dans le dataset désignent maintenant des valeurs agrégées calculées sur la source de données. Pour plus d'informations sur l'agrégation dans la requête, consultez Synthèse des résultats d'une requête (Visual Database Tools).
  Une fois que ces valeurs pré-agrégées se trouvent dans un rapport, vous pouvez continuer à agréger les valeurs tant que vous utilisez une fonction d'agrégation mathématiquement transitive, par exemple SUM. Supposons par exemple que vous disposez d'un ensemble de six valeurs : 1, 2, 3, 4, 5, 6. Si vous groupez les valeurs par paires, vous obtenez un ensemble de trois valeurs : 3, 7, 11. Vous pouvez calculer la somme sur le premier ensemble (21) et calculer la somme du deuxième ensemble (21) ; les sommes sont égales quel que soit le groupement. Si vous calculez la moyenne des valeurs dans les ensembles à l'aide de la fonction AVG, vous obtenez un résultat différent pour chaque ensemble. La moyenne pour l'ensemble des six valeurs est 21/6 ou 3,5. La moyenne de l'ensemble des trois valeurs est 21/3 ou 7. AVG n'est pas une fonction transitive.
• Considérez l'analyse et l'optimisation des performances des requêtes sur la source de données. Par exemple, pour en savoir plus sur l'optimiseur de requête pour SQL Server 2005, consultez Performance des requêtes et Traitement d'une instruction SQL unique.
• Considérez la quantité de données nécessaire pour un graphique. Dans un graphique en courbes, le fait de dessiner des centaines de points dans quelques pixels sur un moniteur entraîne une dégradation des performances et n'améliore pas l'affichage visuel du graphique. Dans un graphique à secteurs, il est préférable de ne pas utiliser plus de sept ou huit secteurs.
• Pour les éléments de rapport avec une visibilité conditionnelle, le processeur de rapport doit appliquer des expressions de groupement, de tri et de filtrage même si seul le niveau supérieur des données est initialement visible. Si l'utilisateur ne souhaite pas toujours visualiser des données détaillées, il est préférable d'utiliser un rapport d'extraction. Les rapports d'extraction ne s'exécutent que lorsqu'un utilisateur clique sur le lien d'extraction dans le rapport principal. Les rapports ou sous-rapports d'extraction traitent toutes les données, même lorsqu'elles sont initialement masquées. Pour plus d'informations, consultez Ajout de liens à un rapport.
• Envisagez la création de captures instantanées d'exécution pour un rapport. Une capture instantanée de rapport inclut toutes les données de rapport extraites pour les datasets dans la définition de rapport. Pour plus d'informations, consultez Captures instantanées de rapport.

Un trafic réseau élevé entraîne des durées d'attente prolongées

De grandes quantités de données passées en tant que trafic réseau peuvent être synonymes de durées d'attente pour l'utilisateur. Si vous connaissez la base utilisateur prévue et le volume de visualisations de rapports prévu, vous pouvez sélectionner la méthode appropriée pour le déploiement des composants de serveur de rapports.

Considérez les stratégies suivantes pour aider à réduire les temps d'attente pour l'utilisateur :

• Conservez la base de données du serveur de rapports sur le même ordinateur que le serveur de rapports.
  La base de données du serveur de rapports tempdb gère les données de rapport extraites pour chaque requête de dataset. Conservez tempdb sur le serveur de rapports afin de réduire le trafic réseau qui peut ralentir l'exécution des rapports.
• Pour les sources de données d'entrepôt de données, conservez l'entrepôt de données sur un serveur distinct du serveur de rapports.
  Bien que l'extraction de données sur le réseau ajoute une tâche supplémentaire pour l'exécution de rapport, le fait d'avoir l'entrepôt de données et Reporting Services sur le même serveur peut ralentir les performances car ils sont tous deux en conflit pour la mémoire.

Pour plus d'informations, consultez Planification d'un déploiement de Reporting Services.

Expiration de délai d'attente de requête

Si le délai d'attente d'une requête de dataset arrive à expiration avant qu'elle ait pu extraire les données, vous pouvez spécifier une valeur de délai d'attente dans le rapport. Cette valeur est par défaut de 30 secondes. Pour définir la valeur du délai d'attente pour une requête de dataset, consultez Procédure : créer un dataset (Concepteur de rapports). Pour plus d'informations, consultez Définition des valeurs de délai d'attente pour l'exécution d'un rapport.

Amélioration des performances de traitement des rapports

Le traitement du rapport se produit une fois que les données ont été extraites pour les datasets de rapport et les paramètres de rapport. Le processeur de rapport combine la disposition du rapport et les données afin de créer un format de rapport temporaire, qui est ensuite passé au module de rendu de rapport. La durée de traitement du rapport peut être affectée par la disposition du rapport, la pagination et les expressions complexes dans les éléments de rapport qui ont de nombreuses instances. Utilisez cette section pour améliorer les performances de traitement de rapport.

Choix de la région de données appropriée

Utilisez des régions de données de liste ou de table dans la mesure du possible. Le traitement d'une table ou d'une liste est plus efficace que le traitement d'une matrice. Les régions de données de liste ou de table prennent en charge les éléments dynamiques uniquement pour les lignes ; les dispositions matricielles prennent en charge les éléments dynamiques pour les lignes et les colonnes, ce qui crée une structure de disposition plus complexe.

Évitez d'utiliser la valeur Nombre total de pages dans l'en-tête ou le pied de page pour les modules de rendu de pages physiques

Une référence au champ global TotalPages peut affecter les performances de traitement de rapport lorsque le rapport est rendu par une extension de rendu de disposition qui effectue une pagination pour les pages physiques, par exemple PDF ou Image. Pour plus d'informations sur les modules de rendu, consultez Éléments d'appréciation à prendre en considération pour le rendu d'un rapport.

Utilisation de groupement de régions de données complexes et de fonctions d'agrégation

Une quantité élevée de niveaux de groupes imbriqués dans une région de données de matrice ou de table peut affecter les performances de traitement de rapport. Vous devez prendre en compte à la fois le niveau de groupement, le nombre d'instances de groupes et l'utilisation des fonctions d'agrégation qui requièrent une évaluation après que les expressions de groupe, de filtre et de tri ont été appliquées.

Évitez les agrégats post-tri. Les agrégats post-tri dépendent de l'ordre de tri et incluent les fonctions suivantes : Previous, First, Last et RunningValue. Lorsque vous incluez une ou plusieurs de ces fonctions dans une expression, le processeur de rapport doit trier les données cibles avant d'appliquer la fonction. Dans la mesure du possible, évitez d'inclure des agrégats post-tri dans des expressions dans des dispositions matricielles qui ont des définitions de groupes complexes, telles que plusieurs groupes adjacents ou imbriqués.

Évaluez la conception du rapport et déterminez si une agrégation des données peut avoir lieu sur la source de données. La réduction de la quantité de données dans le rapport peut suffire à fournir un niveau de performances acceptable sans modifier d'appels de fonctions d'agrégation.

Pour plus d'informations sur les fonctions d'agrégation, consultez Utilisation de fonctions de rapport dans des expressions (Reporting Services).

Spécification de récursivité inutile dans des expressions

Spécifiez une expression parente pour un groupe uniquement si vous définissez une hiérarchie récursive, par exemple un rapport organisationnel qui dresse une liste de responsables et d'employés. La propriété Parent s'applique uniquement aux données récursives. La propriété Parent ne s'applique pas à la relation parent-enfant des groupes imbriqués.

Utilisation de sous-rapports dans une région de données avec de nombreuses lignes

Vous devez vous assurer de bien comprendre les avantages et les inconvénients liés à l'utilisation des sous-rapports. Chaque instance de sous-rapport est une exécution de requête distincte et une tâche de traitement de rapport distincte.

• Utilisez des sous-rapports dans une région de données lorsqu'il n'y a que quelques instances de sous-rapports.
• Évitez d'utiliser des sous-rapports dans un groupe de régions de données lorsqu'il y a de nombreuses instances de groupes. Par exemple, pour afficher une liste de ventes et de retours pour chaque client, envisagez l'utilisation de rapports d'extraction. Déterminez si vous pouvez écrire une requête de manière à joindre les données des clients aux données de ventes et de retours, puis à effectuer un groupement par ID de client.
• Utilisez des sous-rapports lorsque ceux-ci utilisent une source de données différente du rapport principal. Si les performances revêtent une grande importance, envisagez la modification de la requête de dataset dans le rapport principal à l'aide des stratégies suivantes :
  • Recueillez les données dans un entrepôt de données et utilisez celui-ci comme source de données pour un dataset unique.
  • Utilisez des serveurs liés SQL Server et écrivez une requête qui extrait des données à partir de plusieurs bases de données.
  • Utilisez la fonctionnalité OPEN ROWSET pour spécifier différentes bases de données.

Utilisation du tri interactif

Évitez d'utiliser des boutons de tri interactif, à moins que les utilisateurs ne requièrent la capacité à modifier l'ordre de tri des données du rapport.

Utilisation d'images

Vous devez vous assurer de bien comprendre les exigences de ressources pour les images.

• Évitez d'utiliser de grandes images, y compris des images d'arrière-plan. Les grandes images requièrent des ressources de mémoire, de processeur et de rendu, en particulier lorsqu'elles sont rendues avec des modules de rendu tels que PDF, impression ou images de document.
• Évitez d'utiliser de nombreuses instances de petites images à partir d'une base de données ou sur un serveur, par exemple des indicateurs de performance clés. Incluez ces images en tant qu'images imbriquées dans le rapport.
• Pour les rapports qui contiennent de nombreuses images, affectez à la propriété AutoSize des images une valeur différente, telles que Ajuster.

Processus en conflit pour la même mémoire sur le serveur de rapports

Le fait que plusieurs applications soient en conflit pour les mêmes ressources mémoire sur un serveur de rapports peut affecter le traitement des rapports.

Contactez votre administrateur système afin de vérifier que la configuration de gestion de la mémoire est adaptée à votre utilisation du serveur de rapports. Pour plus d'informations, consultez Configuration de la mémoire disponible pour Reporting Services.

L'exécution d'un rapport dépasse le délai d'attente

Pour exécuter de grands rapports, vous devez ajuster deux délais d'attente : le délai d'attente d'exécution de rapport et le d'attente d'exécution ASP.NET.

Les valeurs de délai d'attente d'exécution sont spécifiées sur le serveur de rapports. Pour plus d'informations, consultez Définition des valeurs de délai d'attente pour l'exécution d'un rapport.

La stratégie de délai d'attente ASP.NET est contrôlée par le fichier de configuration du serveur de rapports. L'emplacement par défaut de ce fichier est <drive>:\Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportServer\web.config. Pour définir le nombre maximal de secondes pendant lesquelles une requête peut s'exécuter, affectez comme valeur de l'élément httpRuntime la valeur de délai d'attente en secondes. Le fragment XML suivant indique où ajouter cet élément dans le fichier de configuration :

<configuration>
   . . .
   <system.web>
      . . .
      <httpRuntime executionTimeout="90"/>
      . . .
   </system.web>
   . . .
</configuration>

Pour les requêtes longues ou les rapports complexes, vous devrez peut-être spécifier une valeur qui représente plusieurs heures.

Amélioration des performances de rendu des rapports

Le rendu du rapport a lieu après que les données et la disposition ont été combinées et passées à une extension de rendu. La durée de rendu dépend de la quantité de données, du nombre d'instances d'éléments de rapport et des tailles de pages. Un module de rendu de rapport détermine la quantité de données qui s'ajuste sur une page. La définition d'une page varie d'un module de rendu à un autre. Une page pour le module de rendu Excel est une feuille de calcul. Une page pour le module de rendu PDF, qui peut imprimer un rapport, est la page physique. Une page pour la visionneuse HTML peut être l'intégralité du rapport. La conception du rapport pour une page imprimée peut différer de la conception du rapport pour la visualisation en ligne. Si vous savez que vos utilisateurs visualiseront un rapport dans un format spécifique, concevez le rapport pour ce rapport. Pour plus d'informations, consultez Éléments d'appréciation à prendre en considération pour le rendu d'un rapport.

Les tableaux suivants suggèrent quelques méthodes pour améliorer les performances de rendu de rapport.

Si vous ne parvenez pas à restituer un rapport dans un format, sélectionnez un format qui génère un fichier plus petit, par exemple CSV). Pour un rapport publié, vous pouvez spécifier un format de rendu dans l'URL. Pour plus d'informations, consultez Specifying a Rendering Format in a URL.

Si vous ne pouvez pas sélectionner un autre format car la barre d'outils Rapport n'est pas disponible, vous pouvez définir un abonnement afin de définir un format de rendu et remettre le rapport sous forme de document statique sur un partage de fichiers. Pour plus d'informations, consultez Remise par partage de fichiers dans Reporting Services.

Voir aussi

Concepts

Fichiers journaux de Reporting Services
Traitement des rapports volumineux

Autres ressources

Dépannage de Reporting Services
Erreurs et événements de Reporting Services
Dépannage des problèmes liés aux rapports

Aide et Informations

Assistance sur SQL Server 2005