Discussion :

[tssi555]

Salut,

Dans mon application Vb.NET, je me connecte à une base de données SQL Server. En progressant dans le développement, je me rends compte que mon application est un peu lente pour afficher les données. surtout dans le cas suivant :

- J'ai une interface de recherche, j'entre un code, puis Rechercher, une autre interface s'affiche avec plusieurs onglets différents comprenants des zones de text, combos, grilles, ... alimentés avec des DataSet différents.
Quand j'entre mon code, je remarque un petit temps de "recherche" ou "chargement" puis seulement mon interface affichant les résultats de l'enregistrement recherché.

C'est vrai que je travaille sur une base comprenant des masses de données énormes, mais je veux savoir s'il ya moyen d'acceder à ces données en un temps record sans faire sentir à l'utilisateur le moindre laps de recherche.

Quelqu'un a une idée?
Merci.

[Pol63]

les dataset sont pratique mais sont des classes complexes avec des tas de variables de machins et de bidules
c'est plus long à utiliser que de tout faire "à la main" avec un datareader
m'enfin c'est pas censé plomber non plus (à part sur les datagrid avec au moins 1000 lignes)


sinon il est parfois possible de traiter les données de manière asynchrone, sur un autre thread
et une fois les données acquises il suffit de revenir sur le thread principal pour mettre à jour l'interface (seul le thread principal peut intervenir sur les controles)


il est aussi possible de definir un pool de connexion de plusieurs centaines de connexions, ca evite de perdre du temps à ouvrir la connexion (mot clé à rajouter dans la chaine de connexion)


il faudrait aussi voir si le temps perdu est coté .net ou coté sql server
pour ca il y a sql server profiler, pas évident à comprendre comment ca marche au premier abord mais ca permet de voir le temps passé sur chaque requete qui passe
les requetes qui sont anormalement longues (plusieurs 10aines de ms pour ramener 10lignes) il faut peut etre ajouter des index sur la base et regarder ensuite si ca a changé quelque chose sur le temps d'execution

si ca vient d'sql et/ou que tu veux optimiser sql server il y a des articles très interressants ici
http://sqlpro.developpez.com/

[tssi555]

Merci sperot pour ces explications.
Je pense que le temps perdu est coté .NET vu que je ne me connecte pas encore à la base de donnée "Mode Création", je travaille sur un Mode Développement, enfin, une copie de la base en local. c'est pour ca que je m'inquiète pour le temps qui va encore s'aggraver quand je vais la mettre en route en liaison avec le serveur.
En fait ce que j'ai remarqué en executant plusieurs fois, c'est que le temps perdu est bcp plus apparant à la première fois qu'on on lance l'application, pour le reste, c'est lent, mais pas si lent qu'au début.

[Pol63]

que le serveur soit local ou distant je pense pas que ca change trop
le volume des données par contre oui ...
enfin sqlpro explique que sur une base de données bien pensée et bien administrée, il y a peu de différences entre le début de l'exploitation et 5 ans plus tard

sinon le fait que ca soit lent le première fois, c'est une spécificité de .net, le code est compilé à la volée la première fois qu'il est vu (sub par sub surement ...)
le code compilé est ensuite supprimé du cache à la fin de l'execution etc..

il est possible de compiler un exe .net en exe natif avec ngen fourni par microsoft, ca gagne pas mal de temps à l'ouverture de l'appli

sinon y a des différences de performances notables entre le mode debug et le mode release (ne jamais deployer un exe en mode debug d'ailleurs)
donc tu peux tester en release et hors vs pour voir si c'est pareil

sinon il y a aussi les system.diagnostics.stopwcatch qui sont des chrono, avec .start .stop .reset et .elapsedmilliseconds
en mette un peu partout avec des point d'arret pour voir le temps passé, ca peut aider à voir ce qui prend du temps, ca permet aussi de mettre en évidence le temps entre le premier passage et les autres

[tssi555]

Excellente ton explication.

Le lien de sqlpro est très interessant, mais je ne sais pas si je peux faire grande chose coté serveur ou optimiser la base de données, ce n'est pas moi qui l'ai développer.
En fait, je vais essayé plutôt d'optimiser mon code .Net avec les différentes manières que tu m'a expliquer.

Merci.

[Pol63]

pour compléter :
le code vb.net ou c# est compilé par visual studio en MSIL (langage beaucoup moins lisible mais quand même plus que de l'assembleur)

lors de l'execution il est compilé de MSIL à code natif par le JIT (just in time compiler je crois)


c'est pour ca qu'avec reflector, une exe ou une dll .net sont décompilables dans un des langage .net au choix (alors qu'un exe natif, c'est beaucoup moins décompilables)
par contre utiliser ngen permet d'accélérer le code, mais l'exe .net doit rester sur la machine quand même donc c'est pas une solution pour protéger le code