Discussion :

[binohit]

Bonjour,

Dans mon entreprise j'ai pour mission l'optimisation de la connexion à la BDD Sql Serveur qui est utilisé par une application développée sous Visual Studio 2010 en langage C#.

L'application est l'ERP de l'entreprise développer en interne par l'entreprise.

On a la version 10.50.2500 de SQL Server soit Microsoft® SQL Server® 2008 R2 Service Pack 1.

Dans l'application l’accès à la BDD ce fait systématiquement par ce code(C#):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
using (SqlConnection connex = new SqlConnection(Properties.Settings.Default.base_YakaConnectionString))
{
         connex.Open();
         ....
}

Ce qui ouvre et ferme constamment la connexion à la BDD.

L’application est utilisée à distance via VPN. Lors de cette utilisation a distance, tout est extrêmement ralentit.

Auriez-vous des conseilles à me donner pour effectuer une optimisation ?

Avez-vous une méthodologie particulière avec des étapes à suivre, des tests effectuer et des questions à me poser ?

Cordialement Benoit.

[theMonz31]

bonjour

Ouvrir la connexion et la ferme dans une méthode ne coute pas grand chose car la base de données optimises son "pool" de connexion pour prendre
en compte celà.

Du fait, laisser ouvrir n'apporte à priori aucun gain en performance (ou ultra mineur comme gain)...

Après, le ralentissement vient peut-etre, non pas de la récupération des données dans la base mais de leur exploitation au niveau de l'IHM...

C'est souvent l'IHM qui ralentit les programmes...

[Pol63]

je confirme le pool de connexion, il y en a surement dans sql server, mais il y en a surtout un pour ton appli
la taille de ce pool est modifiable via la chaine de connexion (voir l'aide sur connectionstring, max pool size je crois)
ce qui veut dire que quand tu fermes une connexion, .net la garde de côté et quand tu en rouvres une il te redonne une qu'il a de coté s'il en a plutot que de rouvrir une connexion (qui peut prendre un peu de temps)

après le mieux reste de faire des mesures plutot que des théories
system.diagnostics.stopwatch
tu peux mesurer le temps d'ouverture des connexions (toutes cumulés sur un certain temps d'exécution par exemple), le temps d'exécution d'une requete (executenonquery/executereader), le temps de rapatriement des données etc...

si c'est le temps d'exécution des requetes qui est long il faut regarder pour améliorer les requetes ou ajouter des indexes

si c'est le temps de rapatriement il n'y a pas grand chose à faire (à part si tu utilises des choses comme des dataset, auquel cas tu pourrais gagner un peu, mais pas énormément)
peut etre du fenetrage sinon ...
ou sinon du multithreading, à savoir lire les données sur un thread séparé, et les mettre dans les controles au fur et à mesure, ce qui rend l'interface utilisable avec des données tout de suite et le tout qui arrive au fur et à mesure (montrer graphiquement que ce n'est pas fini de charger dans ce cas)

[binohit]

bonjour theMonz31,

Merci pour ta réponse.

L'effet de "pool" de connexion fonctionnerait si le paramètre Pooling est à TRUE.

En discutant sur un autre forum, on me donnée ce lien : https://msdn.microsoft.com/fr-fr/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.110).aspx

On voit donc par défaut que le paramètre Pooling est à TRUE.

Dans mon cas je réfléchi sur le fait de modifier MinPoolSize à 1 au lieu de 0 par défaut.

Car lorsque le paramètre MinPoolSize est à 0, si le pool n'est pas utilisé pendant un certain laps de temps que je ne connais pas encore, le système ferme automatiquement la connexion.

Donc il me reste à savoir si 'il est plus intéressant de maintenir le "pool" de connexion ouvert (avec MinPoolSize à 1) ou si je le laisse tel quel.

Encore merci pour ta réponse.

[binohit]

Bonjour Pol63,

Merci, je me penche sur les tests que tu me conseilles, cela devrait bien m'aider.

Benoit