Impact sur les performances à l'aide des contrôles ASP.NET

Question

Avec les contrôles utilisateur sur une page, je comprends que chaque contrôle a un impact sur l'utilisation de la mémoire en enregistrant son propre état dans ViewState. Ma question est, combien?

Par exemple, j'ai un formulaire de commentaire sous forme de contrôle sur ma page principale. Il est défini sur Visible = " false " par défaut. Un utilisateur clique sur un bouton de commentaire et le contrôle devient visible lorsqu'il est nécessaire.

Quel serait l’impact relatif sur les performances si le contrôle était placé sur everypage (comme il est situé dans la page principale), mais non visible? Le site que je suis en train de développer aura potentiellement beaucoup de trafic et je me demande si je vais avoir mal à la tête plus tard si les choses ralentissent.

Merci

Answer 1

Les performances pourraient être affectées par le serveur et le client. En premier lieu, vous souhaitez réduire la quantité de HTML, y compris Viewstate, envoyée au client. Si cela se trouve sur chaque page, vous enverrez cette information d'état de visualisation plus souvent que nécessaire.

Je pense que vous devriez avoir une logique qui assure que le contrôle de formulaire de commentaires n’est ajouté qu’à la page de commentaires. Plutôt que d'utiliser visible = " false " ;, placez-le sur sa propre page et créez un lien vers celle-ci, ou ajoutez le contrôle de manière dynamique à la page.

Les principaux avantages seront une utilisation réduite de la bande passante et un rendu plus rapide de la page sur le client. Les avantages secondaires incluent un débogage plus facile et un rendu du code plus propre pour le client.

Avec tous les problèmes de performances, vous devez tester les performances et faire des jugements fondés sur des données tangibles. Dans ce cas, déterminez la taille de l'état d'affichage sur le client, puis multipliez par le nombre de demandes pour afficher la taille d'utilisation de la bande passante sur le serveur. Sur le client, utilisez un outil tel que FireBug pour comprendre la taille globale de la page reçue par le client.

Answer 2

Cela dépend du contrôle. Une grille de données comportant des centaines de lignes peut générer 100 000 Viewstate. De l’autre côté, la case à cocher ne générera pas trop.

Vous pouvez simplement déposer votre contrôle de formulaire de commentaires sur une page aspx vide, le visiter dans le navigateur et rechercher le champ masqué __viewstate. C'est ce que le formulaire de commentaires va ajouter à chaque page en termes d'affichage. Ensuite, vous devrez décider si cela est acceptable.

Je ne voudrais pas penser à une telle optimisation dès le départ. Si cela devient lent plus tard, vous pouvez toujours changer le formulaire pour qu'il soit en HTML pur et utiliser ajax ou quelque chose pour poster les données sur le serveur. Tant qu’il s’agit d’un contrôle de l’utilisateur et non d’un contenu collé, il sera facile d’optimiser