Gridview et lenteur

Version imprimable

16/12/2010, 10h08
topolino

Gridview et lenteur

Bonjour,

j'utilise un gridview avec pagination pour afficher des donnees, tout se passe bien. Par contre une demande fonctionelle vient se rajouter. Les utilisateurs veulent avoir le controle sur le PageSize, mon soucis est lorsque le pagesize est elevé alors l'affichage est tres tres lent du au poids du HTML genere.

Comment puis je palier à cela.

Merci
16/12/2010, 10h21
tortuegenie

Utilise le mode trace pour voir d'ou vient reellement ton probleme.
16/12/2010, 10h28
Nathanael Marchand

Citation:

Envoyé par topolino

Bonjour,

j'utilise un gridview avec pagination pour afficher des donnees, tout se passe bien. Par contre une demande fonctionelle vient se rajouter. Les utilisateurs veulent avoir le controle sur le PageSize, mon soucis est lorsque le pagesize est elevé alors l'affichage est tres tres lent du au poids du HTML genere.

Comment puis je palier à cela.

Merci

Malheureusement, pas de solutions miracle à ceci! Il faut tout simplement limiter le pagesize à un range acceptable pour l'utilisateur au niveau du contenu et des performances. Pour demander plus, il faut passer par une autre méthode comme génerer un rapport sur un server etc.
16/12/2010, 10h31
topolino

Generer un rapport c'est a dire ?
Le pb est le poids de l'HTML genere (2Mo).

Peut on faire un buffer/flush pour que les lignes s'affiches au fur et a mesure ?
16/12/2010, 11h16
ostenhard

Bonjour,

J'ai dernièrement rencontré ce genre de problématique. Déjà as-tu testé ta page sur différents navigateurs ? Quel(s) est(sont) le(s) navigateur(s) cible(s) ?

Que contient ta page ? du javascript ? ... ?

Pour ma part, la dernière fois que j'ai eu ça, en désactivant tout le javascript, la page se chargeait quasi instantanément en affichant environ 300 lignes sur une dizaine de colonne.

Sinon comme il a été dit, que l'utilisateur puisse choisir un pagesize parmi une liste parmi laquelle les valeurs ont un compris acceptable réactivité/taille, c'est plutôt bien. Il faut juste prévenir l'utilisateur qu'avoir plus de lignes affichées sera plus long que moins.
16/12/2010, 11h24
ostenhard

Sinon pour réduire le poids de la page, il y a une bidouille qui consiste à réduire au maximum le HTML généré selon la pratique suivante (tu l'as peut-être déjà fait).

Prenons un exemple grossier, pour chaque cellule tu as défini un style dont le nom de la classe est "styleCellule", donc 12 caractères soit 12 octets. Tu as 100 lignes et 10 colonnes donc 1000 cellules donc dans le HTML généré tu auras 1000 fois "styleCellule" donc 12000 octets. Si tu renommes ton style en "c1" tu gagnes 10 octets à chaque fois donc tu as au final 2000 octets.

Bon c'est un exemple à la c**, mais j'ai eu le cas de développeur utilisant des noms à rallonge pour les styles, les noms d'images, ... qui une fois répétés X fois dans le html donnaient une page de taille importante.
16/12/2010, 11h33
Nicolas Esprit

Je suis du même avis : il y a des choses qui ne sont pas à faire.

La GridView ASP.NET n'est pas prévue pour afficher des milliers d'éléments sur une page Web. En règle générale, une page Web avec un tableau de 1000 lignes est une mauvaise page => très mauvaise ergonomie, faible lisibilité, performances pauvres, etc...

Il faut soit imposer aux utilisateurs, du fait des contraintes techniques, une limite acceptable (200, 500, 1000 ?), selon les colonnes à afficher, le poids de la page, etc.
Soit trouver un autre système qu'une GridView. PitMaverick78 parle d'un report, on peut aussi penser à une extraction Excel. On peut aussi mettre en place du Scrolling Ajax vertical sur la GridView (tu n'a plus à utiliser de pages, mais ne peut visualiser toutes les lignes en même temps).

Bref, pas de solution miracle à ce problème (qui n'en est pas un en fait).

Faut pas se laisser faire par le Business, l'expert informatique c'est toi, pas les utilisateurs. Tu argumentes et explique le pourquoi on ne peut faire ça, tu proposes une solution de contournement, mais tu n'acceptes pas des demandes farfelues :aie:
16/12/2010, 12h56
Nathanael Marchand

Citation:

Envoyé par Nicolas Esprit

Je suis du même avis : il y a des choses qui ne sont pas à faire.

La GridView ASP.NET n'est pas prévue pour afficher des milliers d'éléments sur une page Web. En règle générale, une page Web avec un tableau de 1000 lignes est une mauvaise page => très mauvaise ergonomie, faible lisibilité, performances pauvres, etc...

Je plussoie entièrement!

Citation:

Envoyé par Nicolas Esprit

Il faut soit imposer aux utilisateurs, du fait des contraintes techniques, une limite acceptable (200, 500, 1000 ?), selon les colonnes à afficher, le poids de la page, etc.
Soit trouver un autre système qu'une GridView. PitMaverick78 parle d'un report, on peut aussi penser à une extraction Excel. On peut aussi mettre en place du Scrolling Ajax vertical sur la GridView (tu n'a plus à utiliser de pages, mais ne peut visualiser toutes les lignes en même temps).

J'ai exactement le même problème sur l'appli que je développe actuellement: On affiche que le mois courant. "Oui, mais vous comprenez, des fois, on a besoin d'avoir un historique sur an, toussa toussa".
La réponse qu'on a donné: à besoin spécifique, réponse spécifique. Vous demandez a votre hiérarchie qui dispose de rapports xls, complets, générés par nos serveurs et vous utilisez ca dans votre Excel.

En plus, en général, passer par une demande comme ca, ca freine les ardeurs de ceux qui veulent des stats en long et en large et ils ne demandent que quand ils en ont besoin.

Citation:

Envoyé par Nicolas Esprit

Bref, pas de solution miracle à ce problème (qui n'en est pas un en fait).

Faut pas se laisser faire par le Business, l'expert informatique c'est toi, pas les utilisateurs. Tu argumentes et explique le pourquoi on ne peut faire ça, tu proposes une solution de contournement, mais tu n'acceptes pas des demandes farfelues :aie:

Pfiou, si seulement c'était si simple ;)
Généralement, la technique efficace est de demander quel est la réelle utilité fonctionelle de ce besoin. Bien généralement, le client aura du mal à justifier ou dira qu'il a une utilisation non conforme de l'appli, auquel cas tu peux le remballer! :D
16/12/2010, 13h31
topolino

Si seulement c'etait aussi simple.

Vous savez tres bien que la technique passe en dernier et n'a pas bcp de poids par rapport aux dirigeants. Dans mon cas c'est une demande du big boss. Souvent des solutions genial prennent vie grace aux contraintes drastiques et c'est en cela que notre metier devient interessant.

Sur le principe je suis tout a fait d'accord avec vous, mais sur ce coup la je n'ai pas mon mot a dire et je dois trouver une solution.

Je ne debat pas sur comment une societe devrait marcher mais une aide sur une solution.

Savez-vous s'il est possible d'afficher un gridview ligne par ligne en jouant avec le buffer/flush ?
Ou diminuer les nom generes par le framework qui sont souvent tres long ?

Salut,

Pour remplir ta gridview dynamiquement, tu dois passer par du javascript. Peut etre qu'il existe un composant qui le permet. Sinon, en le faisant à la main, il faut savoir qu'un gridview est transformé en table du coté client. Pour ajouter une ligne en javascript, on peut donc faire :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <script type="text/javascript"> function addRow(content1, content2) { if (!document.getElementById) return; tabBody = document.getElementById("myGridView"); row = document.createElement("TR"); cell1 = document.createElement("TD"); cell2 = document.createElement("TD"); textnode1 = document.createTextNode(content1); textnode2 = document.createTextNode(content2); cell1.appendChild(textnode1); cell2.appendChild(textnode2); row.appendChild(cell1); row.appendChild(cell2); tabBody.appendChild(row); } </script>
Ensuite, il faut faire un petit script javascript qui va chercher les données de la gridview et qui la peuple...

a+

16/12/2010, 15h37
Nathanael Marchand

Sinon un service wcf ajax peut être?
16/12/2010, 15h53
topolino

Peux tu m'en dire plus sur WCF et ajax ?
16/12/2010, 20h43
Nathanael Marchand

Il me semble (mais je suis pas spécialiste la dessus) que tu peux renvoyer une page vide de données et la remplir avec de l'ajax. Cependant tu n'aurais plus le gridview et il faudrait te depatouiller avec du javascript!
20/12/2010, 16h16
lutecefalco

Es-tu vraiment sûr que c'est le poids de la page le problème?
20/12/2010, 16h40
Nathanael Marchand

Citation:

Envoyé par lutecefalco

Es-tu vraiment sûr que c'est le poids de la page le problème?

Ben quand il dit "une page de 2Mo" j'ai envie de dire "Ouch!"
20/12/2010, 16h59
lutecefalco

Citation:

Envoyé par PitMaverick78

Ben quand il dit "une page de 2Mo" j'ai envie de dire "Ouch!"

S'il est en intranet, 2Mo c'est rien
20/12/2010, 17h18
Bluedeep

Citation:

Envoyé par lutecefalco

S'il est en intranet, 2Mo c'est rien

On sait pas : des fois qu'il ait cablé son réseau avec du fil de lampe de chevet :D
20/12/2010, 20h03
Nathanael Marchand

Citation:

Envoyé par lutecefalco

S'il est en intranet, 2Mo c'est rien

Faut voir le parc de PC aussi... 2Mo sur un IE6, ca fait mal! Une grosse partie des parcs entreprises est encore en IE6...
22/12/2010, 08h22
topolino

2Mo les navigateurs n'apprecient pas du tout.
Entre la GridView et le Viewstate y a pas mal de donnees envoyees au navigateur.

C'est pour cela que je pensais a faure un buffer pour afficher au fur et a mesure comme en peux le faire avec d'autre langage.
06/01/2011, 14h19
topolino

Voila une solution que j'ai trouvé. A la place d'utiliser un gridview il est mieux dans mon cas d'utiliser un ListView car il utilise bcp de de viewstate.

Pour en savoir plus je vous laisse ce lien qui sera plus exhaustif :
http://www.beansoftware.com/ASP.NET-...-GridView.aspx
06/01/2011, 14h32
Nicolas Esprit

Après tu peux toujours mettre en place la compression de l'html en sortie, voire la compression du viewstate. Seulement ça augmente la charge CPU de ton serveur.
06/01/2011, 15h52
topolino

La compression HTML au niveau de IIS je suppose ?
Par contre peux tu m'en dire plus sur la compression du Viewstate ?

Bonjour,

Tu peux en effet mettre en place la compression au niveau de IIS (au passage si tu utilises la version 7 je te recommande la lecture de cette article).

Tu peux également appliquer un Filter au niveau de la réponse HTTP. Donc à mettre en place au niveau du Global.asax ou au niveau d'un HttpModule que tu créés. Ceci est un exemple pour illustrer simplement :
Code:

1 2 3 4 HttpContext context = HttpContext.Current; context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress); HttpContext.Current.Response.AppendHeader("Content-encoding", "gzip"); HttpContext.Current.Response.Cache.VaryByHeaders["Accept-encoding"] = true;
Plus généralement au niveau de l'amélioration des performances pour une application ASP.NET j'ai commencé une série de billets pour expliquer (une façon parmi d'autres de) :

Compresser et mettre en cache des images
Minifier, compresser et mettre en cache des fichiers CSS et Javascript
Combiner des fichiers CSS et Javascript

Après ça ne reste que des exemples qui ne seront pas forcément applicables dans tous les contextes. Regarde en priorité les fonctions de compression qu'offrent IIS
Une fois la série plus avancée j'en ferais un article que je publierais sur Developpez.

Concernant l'optimisation générale d'une application Web (ce qui dépasse le cadre de ta GridView) tu peux aussi consulter les recommandations Yahoo et celles de Google. Idéalement pour vérifier et évaluer les points à améliorer sur tes pages je te recommande d'utiliser YSlow de Yahoo et Page Speed de Google. Il existe d'autres outils de ce genre bien-sur.

Pour revenir à ta question concernant la compression du ViewState. Déjà, à titre informatif, il existe un add-on Firefox qui te donne la taille de ton ViewState pour une page aspx.
Généralement il est conseillé des désactiver le ViewState de tous les contrôles ou pages qui n'en ont pas besoin. Moins y en a, mieux c'est.
Concernant la mise en place de cette compression, tu peux regarder sur Google, il existe de nombreux articles/billet mettant en oeuvre cela (comme par exemple ici).

Enfin, si tu actives la compression au niveau de IIS, certains développeurs vont te dire : "c'est stupide de mettre en place la compression du ViewState alors que IIS compresse déjà toute la page, c'est du travail en double". Je répondrais oui et non (ce n'est pas non plus une généralité et dépend de certains paramètres). Il est bon de savoir que lorsque la compression IIS est activée, le client (le browser) reçoit bien des données compressées dont le ViewState. MAIS lors qu'il y a un POST du browser vers IIS, le browser n'envoie pas le ViewState compressé. Or les connections ont toujours un débit UP bien inférieur au débit DOWN. Dans ce cas précis il est utile de mettre en place la compression du ViewState en plus de celle effectuée par IIS.

Sinon pour optimiser une page il faut prendre en compte plusieurs paramètres, notamment le coup CPU niveau serveur, l'impact sur le temps de réponse, etc. Selon le cas, la configuration, les contraintes, on activera ou non la compression.

En espérant ne pas être trop sorti du cadre de ta réponse :aie: et t'avoir éclairé sur le sujet.