Dépannage de rapports : performances de rapport
Lorsque vous affichez un rapport, la première page peut être longue à s'afficher. Pour vous aider à déterminer le temps consacré au traitement de rapport, consultez Techniques de dépannage des problèmes liés aux rapports. Après avoir déterminé si le délai provient de l'extraction de données, du traitement de rapport ou du rendu de rapport, utilisez cette rubrique pour vous aider à résoudre les problèmes.
La récupération de mes données prend trop de temps
Le traitement de mon rapport prend trop de temps
Le rendu de mon rapport prend trop de temps
Conseils de conception pour optimiser le traitement de rapport
La récupération de mes données prend trop de temps.
La quantité de données dans un rapport détermine l'utilisation des ressources, le trafic réseau, le temps de traitement et le stockage nécessaires. Analysez les problèmes présentés dans votre rapport pour déterminer la quantité de données dont vous avez besoin. Ensuite, récupérez ces données des sources de données de rapport.
La récupération porte sur plus de données de rapport que nécessaire
Les opérations de filtre, de tri et d'agrégation sont plus efficaces sur la source de données qu'au cours du traitement de rapport. Écrivez des requêtes pour retourner uniquement le niveau de détail que vous affichez dans le rapport. La liste suivante recense des idées pour évaluer chaque requête de rapport dans le rapport :
Écrivez des requêtes avec des clauses WHERE ou HAVING qui limitent les données à ce que l'utilisateur doit voir dans le rapport. Utilisez les paramètres de requête pour restreindre les données récupérées au moment de l'exécution. Les paramètres de requête sont liés automatiquement aux paramètres de rapport correspondants et permettent à un utilisateur de choisir les données qui les intéressent. Pour plus d'informations, consultez Filtrage des lignes avec les clauses WHERE et HAVING.
Lorsque vous créez un rapport de capture instantanée qui possède des paramètres de rapport qui filtrent les données, toutes les données possibles pouvant ê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ête 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 pour permettre à l'utilisateur de spécifier les données de rapport qu'il souhaite utiliser.
Écrivez des requêtes avec la clause ORDER BY pour trier préalablement les données récupérées pour un rapport. Triez les données dans l'ordre dans lequel vous souhaitez qu'elles soient triées dans le rapport. En raison de leur mode de stockage en mémoire, les données préalablement triées améliorent le temps de traitement de rapport. De nombreuses tâches de traitement de rapport ne nécessitent pas de trier les données avant de les traiter. Par exemple, SUM ne dépend pas de l'ordre. Les données dans des instances de groupe ne sont pas triées automatiquement. Si vous n'avez pas besoin de données triées dans le rapport, ne définissez 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.
Il est beaucoup plus simple, et généralement plus efficace, de trier des groupes ou de trier sur des valeurs d'agrégation dans le rapport que dans la requête.
Écrivez des requêtes avec GROUP BY pour agréger des valeurs sur la source de données.
Dans de nombreux cas, le moyen le plus efficace de communiquer des informations consiste à agréger des valeurs et à afficher des résumés. Vous pouvez calculer un certain niveau d'agrégats sur la source de données et les récupérer pour un dataset. Les données de « détail » dans le dataset représentent désormais des agrégats calculés sur la source de données. Pour plus d'informations, consultez Synthèse des résultats d'une requête (Visual Database Tools).
Une fois que ces valeurs préagrégées figurent dans un rapport, vous pouvez continuer à agréger ces valeurs dans le rapport tant que vous utilisez une fonction d'agrégation qui est mathématiquement transitive, par exemple, SUM. Supposons par exemple que vous disposiez d'un ensemble de 6 valeurs : 1, 2, 3, 4, 5, 6. Si vous regroupez ces valeurs par paires, vous avez un ensemble de 3 valeurs : 3, 7, 11. Vous pouvez calculer la somme sur le premier ensemble (21) puis la somme du deuxième ensemble (21) ; les sommes sont identiques indépendamment du regroupement. Si vous faites 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 de 6 est 21/6 ou 3,5. La moyenne de l'ensemble de 3 est 21/3 ou 7. AVG n'est pas une fonction transitive.
Considérez la quantité de données nécessaire pour un graphique ou une jauge. Le fait de dessiner des centaines de points en quelques pixels sur un moniteur réduit les performances et n'améliore pas la représentation visuelle des graphiques. L'utilisation de plus de 7 ou 8 secteurs dans un graphique à secteurs est contestable. Pour plus d'informations, consultez Préparation des données à afficher dans une région de données de graphique.
Pour les éléments de rapport avec une visibilité conditionnelle, le processeur de rapports doit appliquer les expressions de regroupement, de tri et de filtrage même si le niveau supérieur de données est visible au départ. Bien que le traitement à la demande dans SQL Server 2008 Reporting Services optimise l'évaluation de données en traitant uniquement les données qui sont visibles, toutes les données possibles font partie du rapport. Si l'utilisateur souhaite uniquement afficher des données de détail de temps en temps, l'utilisation d'un rapport d'extraction est conseillée. Pour plus d'informations, consultez Types de rapports.
Envisagez de créer des captures instantanées d'exécution pour un rapport. Une capture instantanée de rapport inclut toutes les données de rapport récupérées pour les datasets dans la définition de rapport. Pour plus d'informations, consultez Création, modification et suppression de clichés dans l'historique de rapport.
Expiration du délai d'attente de la requête
Les valeurs de délai d'attente de la requête sont spécifiées pendant la création du rapport, lors de la définition d'un dataset. La valeur du délai d'attente est conservée avec le rapport, dans l'élément Timeout pour la requête. Elle est par défaut de 30 secondes. Pour plus d'informations, consultez Définition des valeurs de délai d'attente pour le traitement d'un rapport.
Pour définir la valeur du délai d'attente pour une requête de dataset, consultez Procédure : créer un dataset (Reporting Services).
Un trafic réseau important peut entraîner des délais pour l'utilisateur
De grandes quantités de données transitant sur le réseau peuvent occasionner des délais pour l'utilisateur. En fonction de votre base d'utilisateurs attendue et du volume prévu d'affichages de rapport, vous pouvez sélectionner l'approche appropriée pour déployer des composants du serveur de rapports. Pour plus d'informations, consultez Planification d'une topologie de déploiement.
Par exemple, les stratégies suivantes peuvent réduire les temps d'attente pour l'utilisateur :
Conservez le catalogue 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 qui sont récupérées pour chaque requête de dataset dans une définition de rapport. Le fait de conserver les données de rapport avec le processeur de rapports réduit le trafic réseau qui peut ralentir l'exécution des rapports.
Pour les sources de données d'entrepôt de données, gardez l'entrepôt de données sur un serveur distinct du serveur de rapports.
Bien que la récupération de données sur le réseau ajoute une tâche supplémentaire à l'exécution des rapports, le fait que l'entrepôt de données et les services Reporting Services soient en concurrence pour la même mémoire sur le même serveur peut nuire aux performances.
Le traitement de mon rapport prend trop de temps.
Le traitement de rapport a lieu une fois que les données ont été récupérées pour les datasets du rapport, lorsque le processeur de rapports combine la mise en page du rapport et les données pour créer un format de rapport intérimaire qui est ensuite passé au convertisseur de rapport. En général, le processeur de rapports combine les données et la mise en page uniquement pour la page actuelle affichée par l'utilisateur. Le temps de traitement de rapport peut être affecté par la mise en page du rapport, la pagination et des expressions complexes dans les zones d'un rapport qui possèdent de nombreuses instances.
Utilisez cette section pour vous aider à améliorer les performances de traitement de rapport.
Des expressions dans l'en-tête de page ou le pied de page forcent le traitement de toutes les pages
Lorsque vous incluez une référence au champ intégré [&TotalPages], le processeur de rapports doit paginer le rapport entier avant qu'il ne puisse générer le rendu de la première page. Si aucune référence à [&TotalPages] n'existe, la première page peut être rendue et retournée immédiatement à l'utilisateur, sans que le reste du rapport ne soit traité. De plus, le processeur de rapports suppose que toute expression complexe dans l'en-tête de page ou le pied de page peut contenir une référence directe ou indirecte à [&TotalPages].
Pour éviter que le processeur de rapports ne pagine un rapport long, n'incluez pas de référence à [&TotalPages] ou toute expression complexe dans l'en-tête de page et le pied de page.
Le rapport ne contient aucun saut de page
Lorsqu'un utilisateur parcourt un rapport, le processeur de rapports combine les données et les informations de mise en page du rapport pour chaque page de rapport, puis passe la page au convertisseur de rapport. Pour un rapport sans sauts de page, le rapport entier doit être traité avant que l'utilisateur ne puisse afficher la première page.
Un convertisseur de saut de page conditionnel, tel que la visionneuse HTML, gère automatiquement la pagination. Vous pouvez substituer ce comportement automatique et définir le rapport sur une page en attribuant à la propriété de rapport InteractiveHeight la valeur 0. Pour les convertisseurs de saut de page manuel, vous devez ajouter des sauts de page manuellement. Pour plus d'informations sur les types de convertisseurs, consultez Présentation des comportements de rendu.
Vérifiez que la propriété InteractiveHeight n'a pas la valeur 0 et qu'une taille de page raisonnable est définie, par exemple 8,5 pouces. Ajoutez des sauts de page aux éléments de rapport ou aux groupes de tableau matriciel pour vous aider à organiser le rapport en pages. Cela réduit la quantité de données à traiter pour chaque page. Pour plus d'informations, consultez Procédure : ajouter un saut de page (Reporting Services).
Regroupement de régions de données de tableau matriciel complexes et fonctions d'agrégation
De nombreux niveaux de groupes imbriqués et adjacents dans une région de données de tableau matriciel peuvent affecter les performances de traitement de rapport. Tenez compte du niveau de regroupement, du nombre d'instances de groupe et de l'utilisation de fonctions d'agrégation qui requièrent une évaluation après l'application d'expressions de groupe, de filtre et de tri. Par exemple, Previous est une fonction d'agrégation « coûteuse » en ce sens que sa valeur dépend des éléments triés d'une région de données ; Sum n'est pas dépendant de l'ordre et nécessite moins de ressources. First et Last sont d'autres agrégats post-tri. Pour plus d'informations, consultez Utilisation de fonctions de rapport et d'agrégation intégrées dans des expressions (Reporting Services).
Évaluez la conception de votre rapport et déterminez si une certaine agrégation de données peut avoir lieu sur la source de données. Le fait de réduire la quantité de données dans le rapport peut suffire à fournir un niveau de performance acceptable sans modifier les appels de fonction d'agrégation.
De nombreuses instances de sous-rapports dans une région de données de tableau matriciel réduisent les performances des rapports
Vous devez comprendre les avantages et les inconvénients liés à l'utilisation de sous-rapports. Chaque instance de sous-rapport correspond à une exécution de requête séparée et à une tâche de traitement de rapport séparée.
Utilisez des sous-rapports lorsque vous avez seulement quelques instances de sous-rapports.
N'utilisez pas de sous-rapports dans un groupe lorsqu'il y a de nombreuses instances de groupe. Par exemple, pour afficher une liste de ventes et de recettes pour chaque client, envisagez d'utiliser des rapports d'extraction. Déterminez si vous pouvez écrire la requête pour joindre le client aux ventes et aux recettes, puis effectuez un regroupement par ID du client.
Utilisez des sous-rapports lorsque le sous-rapport utilise une source de données différente du rapport principal. Si les performances constituent un problème, envisagez de modifier la requête de dataset dans le rapport principal en utilisant l'une des stratégies de prévention suivantes :
Collectez les données dans un entrepôt de données et utilisez l'entrepôt de données en tant que source de données pour un dataset unique.
Utilisez des serveurs liés SQL Server et écrivez une requête qui récupère les données de plusieurs bases de données.
Utilisez la fonction OPEN ROWSET pour spécifier des bases de données différentes.
Processus en concurrence pour la même mémoire sur le serveur de rapports
Le fait que plusieurs applications soient en concurrence pour les mêmes ressources mémoire sur un serveur de rapports peut affecter le traitement de rapport.
Faites appel à l'administrateur système pour vérifier que la configuration de la gestion de la mémoire est le modèle adapté à votre utilisation du serveur de rapports. Pour plus d'informations, consultez Configuration de la mémoire disponible pour les applications du serveur de rapports.
Expiration du délai d'exécution des rapports
Pour exécuter des rapports volumineux, vous devez ajuster deux délais d'attente : le délai d'attente pour l'exécution de rapport et le délai d'attente de ASP.NET.
Les valeurs de délai d'attente pour l'exécution de rapport sont spécifiées sur le serveur de rapports. Pour plus d'informations, consultez Définition des valeurs de délai d'attente pour le traitement d'un rapport.
La stratégie de délai d'attente de ASP.NET est contrôlée par le fichier de configuration du serveur de rapports. L'emplacement par défaut de ce fichier est <lecteur>:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\web.config. Pour définir la durée maximale, en secondes, d'exécution d'une demande, ajoutez l'élément httpRuntime à ce fichier :
<configuration>
. . .
<system.web.
. . .
<httpRuntime executionTimeout="90"/>
. . .
</system.web.
. . .
</configuration>
Selon la taille du rapport, cette valeur peut représenter plusieurs heures.
Le rendu de mon rapport prend trop de temps.
Le rendu de rapport se produit lorsque les données et la mise en page ont été combinées en un format intérimaire puis passées à une extension de rendu. Le temps de rendu peut être affecté par la quantité de données, le nombre d'instances d'éléments de rapport et la pagination. Lorsque vous exportez un rapport, vous passez le format intérimaire à un convertisseur spécifique. Si vous savez que les utilisateurs affichent un rapport dans un format spécifique, vous devez optimiser le rapport en fonction de ce convertisseur. Pour plus d'informations, consultez Exportation des rapports et Présentation des comportements de rendu.
Utilisez cette section pour vous aider à améliorer les performances de rendu pour un rapport.
Le rapport n'est pas optimisé pour le format de rendu choisi
Certaines fonctionnalités ne sont pas prises en charge par tous les convertisseurs. Si le format principal d'affichage d'un rapport est un format de fichier spécifique, vous devrez peut-être modifier la conception du rapport afin d'optimiser l'affichage pour l'utilisateur.
Ajoutez des sauts de page aux endroits opportuns. Par exemple, chaque saut de page définit une nouvelle feuille dans Excel. Chaque feuille peut gérer 65 000 lignes au maximum. Tenez compte de ces limites lorsque vous définissez les sauts de page dans un rapport.
Pour l'exportation vers Excel, ne fusionnez pas de cellules dans une région de données de tableau matriciel. Dans les rapports au format libre, alignez les éléments de rapport verticalement. Les cellules fusionnées et les éléments de rapport non alignés perturbent le fonctionnement d'Excel dans le rapport exporté.
Les analyseurs HTML ne sont pas efficaces pour le rendu de grandes pages HTML. Si le rendu d'un rapport est source de problèmes, sélectionnez un format qui génère un fichier plus petit (par exemple, CSV). Si vous ne pouvez pas sélectionner un autre format parce que 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 à un partage de fichiers. Pour plus d'informations, consultez Remise par partage de fichiers dans Reporting Services.
Conseils de conception pour optimiser le traitement de rapport
Si les performances de votre rapport constituent l'une de vos préoccupations majeures, utilisez les informations suivantes pour vous aider à optimiser le temps nécessaire au traitement de votre rapport :
Pour les rapports qui possèdent de nombreuses instances de zones de texte, attribuez la valeur FALSE à CanGrow et CanShrink sur les zones de texte. Par défaut, chaque cellule dans une région de données de tableau matriciel contient une zone de texte, ce qui permet au nombre total de zones de texte devant être rendues de croître rapidement.
Pour les rapports qui possèdent de nombreuses images, attribuez à AutoSize sur les images une valeur différente, par exemple Fit.
Pour les zones de texte, évitez d'attribuer la valeur General à la propriété TextAlign. Cette valeur nécessite un traitement conditionnel en fonction du contenu de la zone de texte.
Évitez les sauts de page horizontaux lorsqu'ils ne sont pas nécessaires. Examinez les marges, les largeurs de colonne et les espaces blancs dans un rapport. Par exemple, effectuez le rendu du rapport dans un fichier .TIFF et affichez-le dans l'Aperçu des images et des télécopies Microsoft Windows pour déterminer si les pages supplémentaires sont rendues.
Définissez uniquement la propriété KeepTogether sur les membres de tableau matriciel lorsque vous devez contrôler le comportement de rendu spécifique pour une région de données de tableau matriciel. La fonction KeepTogether nécessite un traitement supplémentaire lorsque les sauts de page sont calculés.