Discussion :

[Falcomix]

Bonjour,

Je viens ici car cela fait plusieurs semaines que je suis confronter à un très gros problème lié à la lenteur de notre application.

Je m'explique :
Nous avons des clients qui veulent utiliser notre logiciel sur plusieurs site distants donc cela implique une ouverture de la BDD à l'extérieur (la dessus tout est OK).
Le gros problème que l'on rencontre, c'est que l'application est très très lente lorsque le logiciel est ouvert à distance.

Donc je viens vers vous, pour savoir quelle solution sera la mieux pour que cette lenteur soit moins importante.

Pour infos : on a essayé le mode DataReader qui est très très lent, le mode DataTable qui est pareil puis ensuite avec un WCF même si on a réussit à gagner du temps cela reste encore trop long.

Merci d'avance.

[zinzineti]

Vous n'aurez pas ici une solution à ce problème de lenteur.
Par contre il y a des pistes à creuser.
Avez-vous fait des tests de monter en charge avant la mise en prod de votre application ?

Face à un problème de lenteur, il faut établir un plan d'action méthodique pour arriver à mettre la main sur la (les) causes de cette lenteur.
Je vous propose donc de provoquer une conf entre les différents acteurs : développeurs - admin réseaux - support - utilisateurs -... pour essayer de comprendre/analyser/mettre en place un plan d'action

du courage

[SQLpro]

Pour infos : on a essayé le mode DataReader qui est très très lent, le mode DataTable qui est pareil puis ensuite avec un WCF même si on a réussit à gagner du temps cela reste encore trop long.

Quand vous dites DataReader et DataTable vous voulez dire que vous faites des accès tables et non des requêtes SQL ???

Parce que si tel est le cas ne vous étonnez pas des lenteurs. Une application client/serveur est conçu pour faire des requêtes SQL, pas des accès table !

A +

[iberserk]

Donnez votre exemple avec le DataReader.

Quel fournisseur d'accès aux données utilisez vous? (ADO.net) à priori.

[Falcomix]

Vous n'aurez pas ici une solution à ce problème de lenteur.
Par contre il y a des pistes à creuser.
Avez-vous fait des tests de monter en charge avant la mise en prod de votre application ?

Face à un problème de lenteur, il faut établir un plan d'action méthodique pour arriver à mettre la main sur la (les) causes de cette lenteur.
Je vous propose donc de provoquer une conf entre les différents acteurs : développeurs - admin réseaux - support - utilisateurs -... pour essayer de comprendre/analyser/mettre en place un plan d'action

du courage

Cela fait parti des tests de charges, on a réussi à gagner du temps suite à l'analyse d'un profiler car on a remarqué qu'un grand nombre de requêtes étaient inutile, ensuite nous avons testé sur différent réseau mais les proportions de latence reste de la même grandeur en fonction de la qualité des liaisons.
Donc c'est pour cela que nous voulons savoir si cela ce fait réellement en production à savoir l'utilisation d'un client lourd avec une BDD SQL Server via internet ?

Quand vous dites DataReader et DataTable vous voulez dire que vous faites des accès tables et non des requêtes SQL ???

Non, on utilise des procédures stockées pour la récupération des données en Base, par contre c'est le mode de communication qui est en DataReader (pour l'extraction des données) et le Datatable (permet de monté en mémoire sur le serveur et puis on transfère le Dataset au client)

[Falcomix]

Donnez votre exemple avec le DataReader.

Quel fournisseur d'accès aux données utilisez vous? (ADO.net) à priori.

On est bien sur du .NET, le Datareader nous permet d'avoir une communication plus performante quand tout est en local, mais par contre avec une liaison distance cela est lent car il faut une connexion continue avec la BDD

[iberserk]

Si vos requètes sont rapide en local et la latence/ performance du réseau est médiocre et que vous ne pouvez pas jouer sur ce levier alors il vous reste à être particulièrement vigilant sur:

• Limiter le nombre de requète
• Limiter le nombre de données retournées (clause SELECT et clause WHERE)

[Falcomix]

Si vos requètes sont rapide en local et la latence/ performance du réseau est médiocre et que vous ne pouvez pas jouer sur ce levier alors il vous reste à être particulièrement vigilant sur:

• Limiter le nombre de requète
• Limiter le nombre de données retournées (clause SELECT et clause WHERE)

En effet on fait un nombre considérable de requête (Analyse du profiler), mais elles sont toutes nécessaires, une option qui peut être envisagé est de récupérer les données prioritaires puis ensuite récupérer les autres éléments dans des threads.

[SQLpro]

En gros en utilisant cette technique du DATAreader, vous faites du EXCEL, pas du SQL !!!
Vous téléchargez la table entière pour aller lire juste une ligne !
Toute votre architecture est a revoir car elle est stupide.
Soit vous ne faites pas de client serveur et traitez tout en local, soit vous voulez bénéficier de la puissance du client serveur et vous devez vous débarrasser de vous datareader et de vos approche "table" !

A +

[Falcomix]

En gros en utilisant cette technique du DATAreader, vous faites du EXCEL, pas du SQL !!!
Vous téléchargez la table entière pour aller lire juste une ligne !
Toute votre architecture est a revoir car elle est stupide.
Soit vous ne faites pas de client serveur et traitez tout en local, soit vous voulez bénéficier de la puissance du client serveur et vous devez vous débarrasser de vous datareader et de vos approche "table" !

A +

On ne télécharge pas la table, on utilise le .net avec DataReader C'est à dire que l'on fait une requête SQL et que l'on récupère le flux avec le DataReader, donc en rien on ne récupère trop de données, on récupère juste le résultat de la requête..

Ensuite cela veut dire que l'on n'utilise plus de ADO .Net ?

[StringBuilder]

SQLPro > Non, "DataReader", en .NET, permet de ligne le résultat d'une requête "ligne à ligne".
Il est réputé plus lent que le mode "DataTable", qui fait la même chose, mais récupère l'ensemble du résultat d'un coup, puisqu'à chaque fetch de ligne il y a un allez-retour sur le réseau.

J'apporte mon fagot sur le tas de bois :
- Contrairement aux idées reçues, préférez DataReader plutôt que DataTable : en effet, si le volume d'information est conséquent, alors DataReader retourne la première ligne dès que le SGBD l'a trouvée. Et la transmission d'une unique ligne sur le réseau est plus rapide que d'un ResultSet entier !
- Utilisez des lectures asynchrones : lisez les quelques premières lignes, et affichez-les avant de lire la suite, en tâche de fond. En effet, dans 99% des cas, l'utilisateur se concentre sur les premières lignes
- Paginez les résultats et limitez le nombre de lignes (utilisation de SELECT TOP n) afin de limiter le volume de données qui transitent sur le réseau inutilement (une requête qui ramène 1000 lignes n'a aucune chance d'être analysée entièrement par l'utilisateur, qui ne lira que les quelques premières dizaines de lignes
- Faites le maximum de traitements côté SGBD : complexifiez vos requêtes (jointures, sous-requêtes, aggrégats, etc.) pour limiter le nombre de requêtes à exécuter pour arriver au résultat final. Essayez aussi d'en faire le maximum dans des procédures stockées, vues, triggers.
- Limitez au maximum le nombre de colonnes retournées : il n'est pas rare de trouver des select * ou autres select <mes 250 colonnes de ma table> alors qu'on n'utilise ensuite qu'un id et un libellé. Vous divisez juste par 10 la capacité de votre connexion réseau.

Voilà, en vérifiant tout ça, vous devriez améliorer pas mal vos performances.
Mais ne vous attendez pas à un miracle !

[Falcomix]

SQLPro > Non, "DataReader", en .NET, permet de ligne le résultat d'une requête "ligne à ligne".
Il est réputé plus lent que le mode "DataTable", qui fait la même chose, mais récupère l'ensemble du résultat d'un coup, puisqu'à chaque fetch de ligne il y a un allez-retour sur le réseau.

J'apporte mon fagot sur le tas de bois :
- Contrairement aux idées reçues, préférez DataReader plutôt que DataTable : en effet, si le volume d'information est conséquent, alors DataReader retourne la première ligne dès que le SGBD l'a trouvée. Et la transmission d'une unique ligne sur le réseau est plus rapide que d'un ResultSet entier !
- Utilisez des lectures asynchrones : lisez les quelques premières lignes, et affichez-les avant de lire la suite, en tâche de fond. En effet, dans 99% des cas, l'utilisateur se concentre sur les premières lignes
- Paginez les résultats et limitez le nombre de lignes (utilisation de SELECT TOP n) afin de limiter le volume de données qui transitent sur le réseau inutilement (une requête qui ramène 1000 lignes n'a aucune chance d'être analysée entièrement par l'utilisateur, qui ne lira que les quelques premières dizaines de lignes
- Faites le maximum de traitements côté SGBD : complexifiez vos requêtes (jointures, sous-requêtes, aggrégats, etc.) pour limiter le nombre de requêtes à exécuter pour arriver au résultat final. Essayez aussi d'en faire le maximum dans des procédures stockées, vues, triggers.
- Limitez au maximum le nombre de colonnes retournées : il n'est pas rare de trouver des select * ou autres select <mes 250 colonnes de ma table> alors qu'on n'utilise ensuite qu'un id et un libellé. Vous divisez juste par 10 la capacité de votre connexion réseau.

Voilà, en vérifiant tout ça, vous devriez améliorer pas mal vos performances.
Mais ne vous attendez pas à un miracle !

D'accord, on va retravailler sur l'ensemble de la base de données et les requête pour voir si jamais cela nous permet d'être un peu moins lent.

[iberserk]

En gros en utilisant cette technique du DATAreader

Euh?
Non Frédéric... le dataReader est juste l'objet qui lit le résultat d'une requète dans ADO.Net.

C'est juste l'objet stockant le résultat de la requète

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
SqlConnexion cnx=new Sqlconnection(chainedeconnexion);
SqlCommand cmd=new SqlCommand("SELECT prenom FROM dbo.DBAS WHERE nom IN('BROUARD','SQLPRO')",cnx);
cnx.Open();
 SqlDataReader dr = cmd.ExecuteReader();
While (dr.Read())
{
 MessageBox.Show (dr[0].ToString());-- Affichage des deux prénoms
}
dr.Close();
cnx.Close();

[Falcomix]

Par contre, est ce que la partie WCF vous semble une bonne solutions pour la communication entre client et serveur ?

Car à l'avenir cette partie WCF deviendra un serveur de synchro.

[SQLpro]

Ha merde, je m'a gourrrrrrrré ! Il faut que je me recycle !!!! ;-)

A +

Euh?
Non Frédéric... le dataReader est juste l'objet qui lit le résultat d'une requète dans ADO.Net.

C'est juste l'objet stockant le résultat de la requète

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
SqlConnexion cnx=new Sqlconnection(chainedeconnexion);
SqlCommand cmd=new SqlCommand("SELECT prenom FROM dbo.DBAS WHERE nom IN('BROUARD','SQLPRO')",cnx);
cnx.Open();
 SqlDataReader dr = cmd.ExecuteReader();
While (dr.Read())
{
 MessageBox.Show (dr[0].ToString());-- Affichage des deux prénoms
}
dr.Close();
cnx.Close();

[Serguei_TARASSOV]

Falcomix,
la méthode plus simple est la prise de traces puis voir le temps d’exécution des requêtes. Si le temps ne pose pas des pb, chercher la lenteur hors SGBD.