Dépannage de rapports : performances de rapport

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 d'instantané 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 l'instantané. 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 Procédure : trier des données dans une région de données (Générateur de rapports version 3.0 et SSRS).

  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 la liste des types de graphiques spécifiques dans Types de graphiques (Générateur de rapports version 3.0 et SSRS).

• 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 façon occasionnelle, l'utilisation d'un rapport d'extraction est conseillée. Pour plus d'informations, consultez Types de rapports.

• Envisagez de créer des instantanés d'exécution pour un rapport. Un instantané 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.

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 et d'un dataset partagé (SSRS).

Pour définir la valeur du délai d'attente pour une requête de dataset, consultez Procédure : créer un dataset partagé ou incorporé (Générateur de rapports version 3.0 et SSRS).

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.

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.

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 (Générateur de rapports version 3.0 et SSRS).

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 (Générateur de rapports version 3.0 et SSRS).

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 Référence aux fonctions d'agrégation (Générateur de rapports version 3.0 et SSRS).

É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.

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.

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.

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 et d'un dataset partagé (SSRS).

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_5.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.

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.