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

[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)

[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]

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.

[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.