none
Lenteur de génération de rapports avec Reporting Services 2005 RRS feed

  • Question

  • Qu'est ce qui peut ralentir considérablement l'exécution de rapports distants en Intranet ?

     

    Notre client dispose d'un site avec 6 ordinateurs d'acquisition de données du type températures, hygrométries, etc.. et d'un serveur d'archivage qui stoke plus de 20 millions d'enregistrements par mois.

     

    Le problème est que cela fonctionne très bien la moitié du temps et que cela est très long l'autre moitié.

     

    Nous n'avons pas trouvé la cause de ces lenteurs.

     

    Quelqu'un pourrait-il me dire quels sont les critères qui pourraient causer ces lenteurs ?

     

    Merci d'avance.

    jeudi 27 septembre 2007 17:56

Toutes les réponses

  • Bonjour,


    As-tu identifié si la lenteur provient de la génération du rapport ou de son affichage ?
    Vie d'un rapport, en gros :
    1. requête SQL/MDX
    2. génération du rapport intermédiaire dans ReportServerTempDB
    3. rendu en HTML
    Sais-tu dans quelle étapde la lenteur se produit ?
    Un bon outil pour la partie SQL/MDX : Générateur de profils (Profiler). Article sur son utilisation ici :
    http://rudi.developpez.com/sqlserver/tutoriel/optimisation/

    vendredi 28 septembre 2007 11:21
  • Je regarderai l'evolution de la taille de la base report servertempdb.

    si tu as un grand rapport et qu'il stocke beaucoup de data temporairement la base reportservertempdb peut etre trop petite et SQL va lancer un extend qui peut prendre du temps.

     

    vendredi 28 septembre 2007 11:39
  • Merci Rudi pour le conseil et le tutoriel d'utilisation du profiler.

     

    Les rapports comportent plusieurs graphiques, chacun associé à un dataset (procédure stockée) différent.

    Je me suis rendu compte que le serveur de rapport demande l'exécution des procédures stockées

    simultanément.

     

    Le problème est que cette exécution porte sur la même table de plusieurs centaines de millions d'enregistrements.

    Les procédures stockées se ralentissement mutuellement.

     

    Le fait de mettre un verrou exclusif sur la table dans chaque procédure stockées

    a grandement amélioré le temps d'exécution.

     

    Il reste un problème :

    Si l'on change les horodates de début et de fin de recherche, le résultat est pratiquement immédiat après une première demande.

    Mais quand l'utilisateur change de rapport, et bien que les rapports en question utilisent la même procédure stockée,

    le rapport est lent la première fois.

     

    Ne pourrait-on pas éviter une recompilation du plan d'exécution de SQL Server entre deux rapports ?

     

    mardi 9 octobre 2007 08:38
  •  lbb_2007 A écrit:

    Le fait de mettre un verrou exclusif sur la table dans chaque procédure stockées

    a grandement amélioré le temps d'exécution.


    Ca m'étonnerait. Peut-être veux-tu dire que tu as mis des NOLOCK ?

    Tu peux, pour du reporting, ajouter en tête de tes sprocs :

    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

    pour baisser le niveau d'isolation de ton code, et diminuer le verrouillage en lecture.


     lbb_2007 A écrit:

    Mais quand l'utilisateur change de rapport, et bien que les rapports en question utilisent la même procédure stockée,

    le rapport est lent la première fois.

     

    Ne pourrait-on pas éviter une recompilation du plan d'exécution de SQL Server entre deux rapports ?



    Comment sais-tu qu'il y a recompilation ? Le vois-tu dans le profiler ?
    N'est-ce pas plutôt le temps de génération du rapport ?
    mardi 9 octobre 2007 14:02
  • Bonsoir,

    J'ai également des problèmes de lenteur avec des rapports reporting service déployés sur 4 serveurs QuadCore tout neuf (4 bases reporting différentes hébergeant les mêmes rapports + 1 serveur de test). J'utilise SQL Server 2005 standard edition sur chacun de ces serveurs. Ce que j'ai pu constaté :

    - le temps d'execution pour 1 même rapport avec les mêmes données. la première execution met 4 fois plus de temps que les suivantes env.

    - en version 2005 Reporting est intégré à IIS. Cela veut dire que si reporting n'a pas été utilisé depuis un certain (paramétrable), le pool retombe et la prochaine execution de rapport entrainera le rechargement depuis 0 de l'application reporting services.

    - et aussi, je n'arrive jamais à avoir le cpu à 100% même pour des rapports qui mettent 4mn à s'executer! le paramètre "Maximum Number of Worker Processes" passé de 1 à 4 sur le pool à un impact faible. je cherche d'autres paramètres sql ou reporting qui jouer sur l'utilisation cpu.

    - j'utilise également "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED", mais de mon point de vue c'est uniquement parce que les tables utilisées pour les rapports sont remplies en // par d'autres process. la commande fait en sorte que ce soient les autres process qui soient "deadlockés" et pas le rapport. S'il n'y a que des access concurrents en lecture, il ne devrait pas de problème : NOLOCK suffit je pense. 

    Pour optimiser les requetes, l'outil MSFT est plutot pas mal :

    http://www.microsoft.com/downloads/en/details.aspx?FamilyId=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en

    Bonne soirée

     

     

     


    jmR
    vendredi 26 novembre 2010 17:59