Grosses requêtes depuis un programme c# / MultiThread

Bonjour,

J'ai un programme qui doit executer des grosses requêtes d'extraction (indépendantes) sur une base SQL Server.

Pour gagner en perf, j'ai eu la (mauvaise ?) idée de découper le travail en plusieurs threads qui se chargent chacun d'une requête.
Le CPU est un 4 coeur. J'ai donc créé 4 threads maxi.

Mes questions sont les suivantes:

- Est ce une bonne approche ?
- Y a t il une optimisation à apporter également dans SQL-Server pour tirer profit des architectures multi-coeur ?
- J'ai parfois cette erreur: Expiration du délai d'attente. Le délai d'attente s'est écoulé avant la fin de l'opération ou le serveur ne répond pas. Je pense que la requête est trop longue et qu'au bout d'un moment, sql server jette l'éponge. Existe t il un moyen d'augmenter la valeur de timeout ?

Merci d'avance

commandtimeout sur la commande si vous êtes en ADO...

qu'utilisez vous pour attaquer votre bdd?

Merci mais j'utilise SqlConnection et SqlCommand.

Attention si tu fais du multri-thread, tu vas exécuter tes quatre requêtes en même temps, ce qui est ton but, cela ne pose pas de problème à SQL serveur d'exécuter plusieurs requêtes (heureusement). Par contre si tu as des expirations du délais d'attente c'est que tes requêtes doivent exploiter les mêmes données et que ses données doivent être verrouillées par une autre requête. Pour pouvoir t'aider d'avantage, il nous faut la structure de la base et les requêtes que tu veux exécuter.


A plus

sqlconnection, sqlcommand=ADO.NET :-)

SqlCommand.CommandTimeOut....

Donnez nous plus détails sur les requète, que font'elle, qu'entendez vous par extraction??

comme le dis jm au cube :-) attention à ce que tes requêtes ne ciblent pas les même données...

Citation:

---

Envoyé par iberserk

sqlconnection, sqlcommand=ADO.NET :-)
comme le dis jm au cube :-) attention à ce que tes requêtes ne ciblent pas les même données...

---

hmmmm
Je suis pas complètement d'accord avec ça...
visiblement, il s'agit de requête SELECT...
Si deux requêtes ont besoin des même données, une seule lecture sera effectuée, et les données seront "envoyées" aux deux requêtes, ça peut donc être un gain de perfs ...

Pour ce qui est des timeouts, il y a aussi peut être moyen d'optimiser les requêtes !
Quels temps de réponse observes-tu pour les requêtes lancée depuis SSMS par exemple ?

Avec quoi n'êtes vous pas d'accord?

Je ne dis que ce n'était pas performant, je dis que si les deux SELECT (comme vous dites...) pointent sur les même tables/données les deux requetes seront plus longues (mais la sommes des deux le serait plus encore...) ce qui peu expliquer qu'il doivent augmenter un peu le CommandTimeOut de sa SqlCommand ADO...

Citation:

---

une seule lecture sera effectuée

---

Je n'avais pas vu... là c'est moi qui ne suis pas d'accord... pour la deuxième requête les données seront probablement en cache mais s'il y a deux requêtes différentes il y a forcément deux lectures des données que ce soit de manière physique ou logique...

Citation:

---

Envoyé par iberserk

il y a forcément deux lectures des données que ce soit de manière physique ou logique...

---

Celle-ci est bien plus rapide que celle-là, qui est à éviter tant que possible !

D'autre part, même si chaque requête engendre une demande de lecture, elles seront mutualisées au niveau du moteur de stockage, pour n'en faire plus qu'une et ainsi optimiser le tout.

Donc le fait que les requêtes ciblent les mêmes données ne sera pas forcément un handicap, voire même pourra être un avantage.

Là où je suis d'accord avec vous par contre, c'est qu'on a trop peu d'informations pour répondre aux questions posées. Il est en effet difficile de résoudre un problème sans en connaitre la cause, et il faudrait donc commencer par savoir pourquoi ces requêtes sont lentes !

Mais globalement, je pense qu'il sera beaucoup plus rentable de chercher à optimiser les requêtes (réécriture, indexation,...) plutôt que de chercher à paralléliser les requêtes. Surtout que SQL server est capable de tirer parti d'un multi-coeur, et peut même paralléliser l’exécution d'une requête donnée, s'il estime que c'est avantageux.

Citation:

---

Mais globalement, je pense qu'il sera beaucoup plus rentable de chercher à optimiser les requêtes (réécriture, indexation,...) plutôt que de chercher à paralléliser les requêtes. Surtout que SQL server est capable de tirer parti d'un multi-coeur, et peut même paralléliser l’exécution d'une requête donnée, s'il estime que c'est avantageux.

---

+1 dans votre club :-)

Il a de grande chances en effet que les requête ne soient pas optimales...

En revanche même optimisées le timeout par défaut de la commande ADO est de 30 secondes si je ne m'abuse... cela risque de faire juste si le volume des données et/ou la complexité sont important.

Alors est-ce une bonne approche boby62423? si vous ne multithreadez pas vos appels de requètes la seconde ne se lancera qu'après la fin de l'execution de la première...
Comme vous l'explique aieeeuuuuu la seconde, si elle est basée sur les même données sera plus rapide car les données seront en cache...



Peut-on aussi voir vos requêtes ou est-ce indiscret?

Citation:

---

Envoyé par aieeeuuuuu

Celle-ci est bien plus rapide que celle-là, qui est à éviter tant que possible !

D'autre part, même si chaque requête engendre une demande de lecture, elles seront mutualisées au niveau du moteur de stockage, pour n'en faire plus qu'une et ainsi optimiser le tout.

Donc le fait que les requêtes ciblent les mêmes données ne sera pas forcément un handicap, voire même pourra être un avantage.

---

Cette technique n'est disponible que dans la version enterprise... (advanced scanning).

A +

Citation:

---

Envoyé par SQLpro

Cette technique n'est disponible que dans la version enterprise... (advanced scanning).

A +

---

Connaitre la version de SQL Server est donc une question qui vient s'ajouter à la liste des questions à se poser pour répondre au problème initial de boby62423 (lequel est semble-t-il plongé dans du débogage de multithreading sous C# :mouarf:)