Discussion :

[hokidoki]

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

[Chubyone]

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.

[hokidoki]

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.

[lopesmauricio]

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.

[jeanjean0403]

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.

[nasimpat7]

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.

@+

[Xahel]

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.