Quels sont les moyens génériques de rendre les services de reporting plus rapides?

Question

Bien que je comprenne cette question est assez vague puisque je ne vous donne pas autant de détails que je le voudrais, j'espère des améliorations générales qui peuvent être fait à mon code de génération ou les rapports eux-mêmes pour les accélérer. J'ai demandé plus de matériel, mais j'ai été refusé.

public Stream GenerateReport(string reportName, string format) 
{ 
    if (reportName == null) 
     throw new ArgumentNullException("reportName"); 

    reportExecutionService.LoadReport(reportName, null); 

    string extension; 
    string encoding; 
    string mimeType; 
    ReportExecution2005.Warning[] warnings; 
    string[] streamIDs; 

    byte[] results = reportExecutionService.Render(format, null, out extension, 
     out encoding, out mimeType, out warnings, out streamIDs); 

    return new MemoryStream(results); 
} 

Les rapports eux-mêmes prennent 6 à 10 secondes chacun. J'ai réduit le goulot d'étranglement à Reporting Services lui-même. Où dois-je commencer à chercher à éliminer les goulets d'étranglement potentiels de vitesse. Note: du code a été retiré pour protéger les innocents.

Answer 1

Bien que pas directement lié au code affiché, voici quelques améliorations génériques, vous devez toujours tenir compte lors de la rédaction des rapports dans Reporting Services:

1. tableaux de rapports pré-charge afin qu'ils agrègent déjà une les données qui auraient été agrégées dans le rapport. Par exemple, si la source de données du rapport résume des milliers de lignes de données et nécessite de joindre plusieurs tables, vous devez créer une table pré-agrégée qui réunit toutes les données et résume déjà les données au grain requis pour le rapport.

2. Si vous transmettez des paramètres dans la source de données, la table sous-jacente agrégée doit avoir un index cluster qui correspond à la manière dont la table sera recherchée. Par exemple, si le rapport affiche uniquement des données pour un client individuel et pour une période de transaction donnée, l'index clusterisé doit être commandé sur le client et la date de la transaction.

3. Les données de filtrage doivent apparaître dans la requête de source de données et non dans le rapport lui-même. Cela signifie que si vous paramétrez votre rapport pour qu'il filtre les données, les paramètres doivent être transmis à la base de données afin qu'elle renvoie un ensemble de données plus petit. Ne renvoyez pas un grand nombre de données, puis filtrez les données. Il est facile de commettre cette erreur lors de l'utilisation d'un paramètre à valeurs multiples, car les instructions prêtes à l'emploi pour l'utilisation de paramètres à valeur multiple consistent à filtrer les données APRÈS que les données ont été renvoyées à Reporting Services.

J'espère que vous faites déjà ce qui précède et que ce n'est pas un poste pertinent. :)

Answer 2

Si vous l'avez réduit à Reporting Services uniquement en fonction de votre code client, je passerais en revue les requêtes/SP qui récupèrent vos données. J'ai rencontré quelques requêtes assez méchant dans ma journée qui a semblé assez innocent.

Answer 3

Je viens de faire quelques rapports vraiment désagréables! J'ai dû rejoindre des critères ombrés sur plusieurs tables contenant quelques millions de lignes chacune.

J'ai terminé la création d'une application de console pour faire la collecte tous les soirs de la veille. Cela devenait trop lourd avec toute la logique, la génération du rapport prenait simplement trop de temps. Maintenant, la vitesse n'est plus un problème.

Cela dépend du type de rapport. Ces trois rapports avaient seulement besoin des chiffres d'hier. Mais comme le dit Austin, les requêtes ou quoi que ce soit est généralement le goulot d'étranglement. Une autre chose à retenir est que le rapport "expire" après un certain temps (c'est le réglage par défaut). Donc, si vous n'avez pas utilisé le rapport pendant un certain temps, il faut un peu plus de temps pour générer. Si vous le faites à nouveau immédiatement après le prochain est plus rapide.Contournement pour cela serait d'aller au rapport dans Internet Explorer et cliquez sur les propriétés et jeter un oeil à l'exécution et l'histoire (ils peuvent être modifiés pour améliorer le rendu des rapports) Attention, si les données sont critiques, vous pourriez vous retrouver .