WDForge.org - Forums - WD 9

Index des forums WDForge.org

WD 9

SQL et threads

Bas

Suivant S'enregistrer pour contribuer

	SQL et threads	#1
Animateur WDF Inscrit: 26/06/2002 16:24 De wdforge.org Post(s): 2822	Bonjour Dans un traitement d'analyse statistique, nous exécutons un certain nombre de requetes SQL par enregistrement. Une fenêtre a été crée pour afficher ces informations pour un enregistrement... L'utilisateur ne sera pas pénalisé par la petite seconde d'attente. En revanche, devant faire des états donnant ces informations pour une liste d'enregistrement, le problème se corse. Avec La seconde d'exécutions des requêtes par ligne, même en préparant le tout dans un fichier temporaire, cela risque trés vite de devenir long. D'où l'idée d'utiliser les threads... et l'appel à expériences. Contribution le : 18/03/2005 15:51
	_________________ R&B Contact, CV.

	Re: SQL et threads	#2
DSI WDF Inscrit: 15/03/2005 14:22 Post(s): 238	C'est quoi comme SGBD? Avec access qui effectuait des traitements dans un thread, il y avait des disfonctionnements ingérables. Sinon, n'est il pas possible de préparer le contenu entier de ce qui va etre édité en amont? Contribution le : 18/03/2005 16:45
DSI WDF Inscrit: 15/03/2005 14:22 Post(s): 238

	Re: SQL et threads	#3
Inscrit: 19/11/2002 12:20 Post(s): 390	En général, quand j'essayais de cumuler threads + grosse requêtes (accès disques intensifs, mémoire), ça avait le don de prendre beaucoup trop de temps CPU à Windows, et au bout d'un moment, le soft explosait, Windows le fermait manu militari... Depuis, je ne fais plus que des traitements "légers" dans les threads, ou alors j'utilise des exe séparés, comme autant de threads... Contribution le : 18/03/2005 21:21
Inscrit: 19/11/2002 12:20 Post(s): 390

	Re: SQL et threads	#4
Animateur WDF Inscrit: 26/06/2002 16:24 De wdforge.org Post(s): 2822	Merci, @Ben-34 : Il s'agit d'une base HyperFile. La préparation poserais bien des problèmes : les SQL portent sur un nombre conséquent des fichiers (mais je vais étudier le coup). @Lmame : ok. Les requetes sont principalement des sommes sur des paires de fichiers (entête + ligne avec date dans l'entête, code + quantité dans lignes, IDAuto en liens). Contribution le : 21/03/2005 08:32
	_________________ R&B Contact, CV.

	Re: SQL et threads	#5
Animateur WDF Inscrit: 26/06/2002 16:24 De wdforge.org Post(s): 2822	Après quelques recherches, j'ai du repenser la méthode de lancement de mes requêtes. Précision : - le traitement en cours d'optimisation est simple. Il faut produire un état statistique sur la base de données. Pour une sélection d'enregistrements et une période, on va, pour chacun, aller récupérer des cumuls dans différentes paires de fichiers "entête-lignes". Ces cumuls serviront de termes dans l'opération de calcul final à afficher dans l'état. Dans le détail, pour chaque enregistrement de la sélection (pouvant aller jusqu'à 100 000 enregistrement par exemple), on va lancer dans une majorité de cas un train de 6 requêtes SQL. nutile de penser alors laisser ce traitement à 1 seconde par ligne ! Pourquoi des requêtes : parce que les informations qui servent à effectuer le cumul se trouvent à chaque fois dans deux fichiers liés (Entete : Date (pour la période), Ligne : Code cherché + Valeur cumulée). Les requêtes semblent la méthode préconisée pour ce type d'accès. Les requêtes sont dans ce genre : `SELECT SUM(LIGNE.RUBCUMUL) AS CUMUL FROM LIGNE,TETE WHERE TETE.IDTETE = LIGNE.IDTETE AND LIGNE.CODE = {Param1} AND TETE.DATE >= {Param2} AND TETE.DATE <= {Param3} GROUP BY LIGNE.CODE` On remarquera que le résultat est réduit à sa plus grande simplicité : une ligne et une rubrique. L'objectif est bien à l'optimisation. Contrainte : ce traitement étant utilisé dans deux fenêtres, nous somme partis sur une classe en charge de ces calculs et du lancement des requête. Ce que nous avons fait : Nous nous sommes penché sur l'exemple WinDev "Pool de thread" et en avons pris le mécanisme de lancement des requêtes. Un compteur de thread, un tableau de la liste des requêtes (:m_tReq) et de leur résultat (:m_tRes). Une méthode d'initialisation de sémaphore (???) et d'arret des threads. Une méthode de lancement de requêtes (thread_requete) et celle de sont lancement (Thread_Lance). PROCEDURE Thread_Requete(nNumRequete,pnThread) // // On indique que le thread s'est chargé et lancé ThreadEnvoieSignal(".") // Contrôle du nombre de thread à un instant t grâce aux sémaphores (???) SémaphoreDébut("SEM_LIMITE") bResExecute est un booléen SectionCritiqueDébut(":Thread_Requete") bResExecute = HExécuteRequête(:m_tReq[nNumRequete],hRequêteDéfaut,:m_cCI,:m_dDeb,:m_dFin) SectionCritiqueFin(":Thread_Requete") SI bResExecute ALORS SI HLitPremier(:m_tReq[nNumRequete]) ALORS :m_tRes[nNumRequete]={:m_tReq[nNumRequete]+".QTE",indRubrique} FIN FIN HAnnuleDéclaration(:m_tReq[nNumRequete]) // On peut libérer une unité du sémaphore SémaphoreFin("SEM_LIMITE",1) // Arrêt du thread ThreadArrête("") PROCEDURE Thread_Lance(pnIndice) // lance la requête de l'indice Sablier(Vrai) // On exécute le thread ThreadExécute(:m_cNomThread+:m_nThread,threadNormal,":Thread_Requete",pnIndice,:m_nThread) // On attend que le thread se soit lancé ThreadAttendSignal() // On incrémente le numéro du thread en cours :m_nThread ++ Sablier(Faux) Le but est de lancer les requêtes et attendre que toutes soient exécutées pour passer à la suite... Il s'agit donc, semble-t il, de synchroniser non pas deux mais plusieurs threads (cet exemple en synchronise deux)... et sur le sujet à part la liste des fonctions relatives aux signaux, les exemples sont rares. Contribution le : 23/03/2005 08:22
	_________________ R&B Contact, CV.

	Re: SQL et threads	#6
Animateur WDF Inscrit: 26/06/2002 16:24 De wdforge.org Post(s): 2822	La gestion des zones critiques et des sémaphores semble inutile dans ce cas. Nous allons vois simplement du coté du contenu d'une liste des theads en cours... le pool. En effet, nous souhaitons poursuivre nos traitements qu'une fois toutes les requêtes exécutées. Contribution le : 23/03/2005 09:05
	_________________ R&B Contact, CV.

	Re: SQL et threads	#7
Inscrit: 19/11/2002 12:20 Post(s): 390	Oui, les sémaphores ne servent pas à grand chose dans votre cas, sauf peut être à terme à voir le nombre de threads (requêtes) à lancer au maximum à un instant "t" donné selon les performances du PC... Mais dans ce cas, il est peut être plus simple de gérer l'état d'un thread par une liste de requêtes à exécuter dans une table (ou tableau mémoire), et que le thread principal voit le nombre de threads en cours, en lance un certain nombre, et checke l'état des threads par un ThreadEtat() plutôt que de faire du signal... C'est ce que j'ai fait pour une poule pondeuse qui lance près de 300 threads, chacun étant un dialogue avec une autre appli via fichier texte... et ça tourne ;) Contribution le : 23/03/2005 09:25
Inscrit: 19/11/2002 12:20 Post(s): 390

	Re: SQL et threads	#8
Animateur WDF Inscrit: 26/06/2002 16:24 De wdforge.org Post(s): 2822	Voila ! Sauf qu'il me reste à effectuer un comparatif, épurer le code des essais infructueux et documenter : cela semble enfin fonctionner. Une petite explication suivra car c'est un sujet fort interessant que de lancer un train de requêtes SQL et d'attendre le résultat. En tout cas cela ne fut pas si simple qu'il n'y parrait. Merci aux intervenants de cette discussion ! Contribution le : 24/03/2005 17:34
	_________________ R&B Contact, CV.

Haut

S'enregistrer pour contribuer

Vous ne pouvez pas débuter de nouveaux sujets.

Vous pouvez voir les sujets.

Vous ne pouvez pas répondre aux contributions.

Vous ne pouvez pas éditer vos contributions.

Vous ne pouvez pas effacez vos contributions.

Vous ne pouvez pas ajouter de nouveaux sondages.

Vous ne pouvez pas voter en sondage.

Vous ne pouvez pas attacher des fichiers à vos contributions.

Vous ne pouvez pas poster sans approbation.