1. #1
    Membre régulier
    Profil pro
    Inscrit en
    avril 2006
    Messages
    161
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : avril 2006
    Messages : 161
    Points : 77
    Points
    77

    Par défaut Optimisation du temps de chargement des pages d'un gridview

    Bonjour,

    J'ai un gridview qui contient 2000 lignes. La requête sql pour charger les données est très longue.

    Ayant activé la pagination de mon gridview, pour chaque page il refait la requête et c'est très long.

    J'ai vu dans la FAQ qu'il ne fallait pas utiliser le ViewState pour garder en mémoire le résultat mais plutôt utiliser les variables de session.
    Le problème est que autant de données peuvent également surcharger la mémoire vive sur le serveur web :
    http://dotnet.developpez.com/faq/asp...utobjetsession

    Comment sais t-on si les données que l'on met en variable de session sont trop importantes ?

    Au final ya t-il un moyen simple pour ne pas avoir a relancer ma requête à chaque changement de page (a part changer la requête sql car je ne suis censé que travaillé sur la partie interface de l'application) ?

    Merci de votre aide

  2. #2
    Membre éclairé
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    700
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : juillet 2005
    Messages : 700
    Points : 804
    Points
    804

    Par défaut

    La Session sert stocker des données de... Session! N'Y STOCKES PAS des données de page.
    Une page : 2000 lignes ; une autre page? 500 lignes? Le prochain dev va faire un copier coller : encore quelques milliers de lignes?...


    Le premier intéret du paging est l'ergonomie Utilisateur : ok. Mais son second intéret est aussi de limiter le transit des données entre le serveur SQL et ta WebApp...
    L'idéal ici serait de retoucher ta requête, pour prendre en compte l'index début et le nombre max d'enregistrements.


    Mais pour moi il faudrait surtout vérifier la requête en soi. Ça veut dire quoi "long"?...
    Parce que 2000 lignes, c'est ridicule... Si ta requête est complexe, il faudrait peut être se pencher sur son optimisation, voir celle des tables intéressées.


    Si tu estimes vraiment qu'il peut être intéressant de conserver tes données coté WebApp, regardes du coté du caching des ObjectDataSource.

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    avril 2006
    Messages
    161
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : avril 2006
    Messages : 161
    Points : 77
    Points
    77

    Par défaut

    Citation Envoyé par Chubyone Voir le message
    La Session sert stocker des données de... Session! N'Y STOCKES PAS des données de page.
    Une page : 2000 lignes ; une autre page? 500 lignes? Le prochain dev va faire un copier coller : encore quelques milliers de lignes?...


    Le premier intéret du paging est l'ergonomie Utilisateur : ok. Mais son second intéret est aussi de limiter le transit des données entre le serveur SQL et ta WebApp...
    L'idéal ici serait de retoucher ta requête, pour prendre en compte l'index début et le nombre max d'enregistrements.


    Mais pour moi il faudrait surtout vérifier la requête en soi. Ça veut dire quoi "long"?...
    Parce que 2000 lignes, c'est ridicule... Si ta requête est complexe, il faudrait peut être se pencher sur son optimisation, voir celle des tables intéressées.


    Si tu estimes vraiment qu'il peut être intéressant de conserver tes données coté WebApp, regardes du coté du caching des ObjectDataSource.
    Bonjour,
    Le problème de retoucher la requête pour prendre en compte le paging c'est que l'on crée une dépendance entre l'interface et l'accès aux données, actuellement je pourrais très bien afficher mes données dans une seule page, sur un graphique ou dans un tableau paginé comme je le fait.
    "Long" signifie environ 1 minute, pour un utilisateur cela est rédhibitoire de devoir attendre 1 minute avant chaque chargement de page. Pour l'optimisation je n'aurai pas le temps de me pencher la dessus mais cela serai en effet intéressant.

    Merci de ton aide.

  4. #4
    Candidat au Club
    Profil pro
    Inscrit en
    mars 2010
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : mars 2010
    Messages : 3
    Points : 4
    Points
    4

    Par défaut Solution!

    Bonjour,

    As-tu trouvé une solution pour ton temps de chargement?
    J'ai ce même problème mon site SP prends plus de 1 minute pour charger...

    Merci,
    Mauricio.

  5. #5
    Membre du Club
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    72
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2006
    Messages : 72
    Points : 66
    Points
    66

    Par défaut

    bonjour,

    un viewstate est effectivement très long à charger mais il a le mérite de ne se charger qu'une seule fois, ce qui est déjà une amélioration par rapport à ta pagination de ton gridview.

    Tu dis que ta requete SQL est longue... Combien de temps met-elle à s'exécuter ? Il y a toujours moyen d'optimiser une requête SQL...

    Un autre point, est-ce que tes données sont statiques (type référentiel) ? Si c'est le cas, tu peux charger ta requette en cache au démarrage de l'application et non au niveau de la session.

  6. #6
    Membre habitué
    Profil pro
    Développeur Web
    Inscrit en
    septembre 2007
    Messages
    173
    Détails du profil
    Informations personnelles :
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2007
    Messages : 173
    Points : 161
    Points
    161

    Par défaut

    Je te propose la solution suivante:

    1) je te conseil de passer par un Dataset pour sourcer ta grid.
    2) Au chargement de ta page tu charge une propriété de type Dataset par le biais d'une méthode retournant un DataSet.
    3) Tu met ce DataSet en cache, ce qui te permettra d'éviter les aller/retour en base.
    4) Pour filtrer tes données, fais une méthode qui te renvoie un DataView à laquelle tu passe en paramètre ton DataSet (En cache) et éventuellement la page.

    Le DataView te permet de filtrer les données contenu dans ton DataSet sans pour autant supprimer les données initiales. Utilise pour cela la propriété RowFilter dans laquelle tu pourra mettre les conditions liées à ta pagination.

    Tu peux bien sure directement sourcer ta grid à partir d'un DataView.

    Espérant que ça puisse t'aider.

    @+

  7. #7
    Nouveau membre du Club
    Profil pro
    Développeur informatique
    Inscrit en
    septembre 2010
    Messages
    48
    Détails du profil
    Informations personnelles :
    Âge : 29
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : septembre 2010
    Messages : 48
    Points : 28
    Points
    28

    Par défaut optimisation

    salut

    en utilisant les viewgried,j'ai remarqué que c'était pas forcément les requêtes qui prennent du temps, mais l'affichage des lignes dans la viewgried.

    Par exemple j'ai une requête qui s'exécute en 50 ms, mais qui prend 30 secondes à s'afficher.
    Car dans mes lignes j'ai des couleurs des boutons, de la mise en forme ...

    par contre j'ai fais le même affichage juste avec les valeurs de la base de données brute dans les lignes j'obtiens un temps de 6 secondes.

    donc à voir ce qu'il faut optimiser.

Discussions similaires

  1. Réponses: 1
    Dernier message: 01/11/2012, 12h27
  2. calculez le temps de chargement des pages
    Par unix27 dans le forum ASP.NET
    Réponses: 2
    Dernier message: 09/03/2009, 09h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo