Conception - Thread bouclant à l'infinie pour la persistance des données

Bonjour les jeunes, Ça farte ? :mrgreen:

J'ai une question de conception à vous soumettre. Je viens de reprendre une application web en dotnet qui utilise un algorithme qui me laisse plutôt perplexe.
Je souhaiterais avoir votre avis là dessus.

L'application web utilise beaucoup de liste déroulante et ses listes déroulante sont issue de requêtes SQL. Afin d'éviter de requêter systématique en base de données à chaque affichage de liste, le développeur qui a conçu cette application à imaginé un stockage persistant des variables (quelques minutes).

Pour faire ça, il lance un Thread qui fait un :

Code:

---

1 2 3 4 5 6 7 8 9

while (True) { // Mise à jour de chacune des listes // ....   // Pause de quelques secondes avant de recharger les listes Thread.sleep(30000); }

---

Et donc, ce Thread qui est une bloucle infinie tient à jour une variable qui est récupérée par le Thread principale de chaque page.

Avez-vous déjà vu un fonctionnement comme ça ?
Cet algo vous parait-il délirant ?
Connaissez vous un moyen (librairie, composant, ...) permettant de faire de la mise en cache d'objet partagés en .net ?

Merci d'avance.

Salut,

Vu comme ça ça ne parait pas délirant, juste la seule solution que le développeur a trouvé au moment où il a développé le code. Maintenant, c'est le résultat qui compte.

Après si on cherche à améliorer les performances on peut mettre à jour les listes lorsque c'est seulement nécessaire. On peut imaginer que quand la liste est modifiée un bout de code informe les serveurs web de se mettre à jour (via une requête http).

A+

j'ai l'impression que le gars ne connaissait pas le cache d'asp.net ;)

http://msdn.microsoft.com/fr-fr/libr...=VS.80%29.aspx

Et ce système de cache fonctionne également avec une connexion en base de données ? L'idée serait de stocker une connexion pour la réutiliser

Si tu n'as pas trop de données à stocker, tu peux utiliser des variable de session, dans lesquelles tu peux mettre ce que tu veux. Mais enfin typiquement une connection, ca se configure dans le web.config et tu en recrées une à chaque fois que tu fais des requetes, je ne vois pas trop l'interet de garder une même connection sur la durée (à la limite si t'as des tables temporaires, et encore...).

Citation:

---

Envoyé par arnolem

Et ce système de cache fonctionne également avec une connexion en base de données ? L'idée serait de stocker une connexion pour la réutiliser

---

Surtout pas, malheureux !!

Une connection doit être ouverte le plus tard possible, et détruite le plus tot possible...sinon, tu risque de saturer ton serveur ;)

Citation:

---

Envoyé par Philippe Vialatte

Surtout pas, malheureux !!

Une connection doit être ouverte le plus tard possible, et détruite le plus tot possible...sinon, tu risque de saturer ton serveur ;)

---

C'est marrant ce que tu dis là. Peux-tu aller plus loin dans ta pensé ?

Parce que l'application que je reprends, utilise ce principe des Thread avec une boucle infinie pour mettre en cache des listes de données mais également pour gérer un pool de connexion. Ce qui se passe c'est que ce Thread ouvre une 50ène de connexion à la base de données et les redistribue dès qu'un script en a besoin. Ensuite, la connexion est rendu.

Vous trouvez ça également inutile ?

Citation:

---

Envoyé par arnolem

Vous trouvez ça également inutile ?

---

Complétement, le framework .NET gère son pool de connexions comme un grand ;)

Citation:

---

Envoyé par lutecefalco

Complétement, le framework .NET gère son pool de connexions comme un grand ;)

---

Si d'autres peuvent également me donner leur point de vue là dessus, je suis preneur.

En effet, si je dois supprimer toute cette couche de l'application, je ne voudrais le faire de manière sur.

Voici plus de détails sur le fonctionnement.

1. Un Thread infinie ouvre X connexions en base et les stocks dans un pool de connexion
2. Chaque script demande une connexion et la rend dès qu'il a fini
3. Dès que le Thread infinie détecte que toute les connexions sont utilisées, il ajoute Y connexions de plus dans le pool

Tout cela ce fait dans le but d'économiser le temps d'ouverture de connexion à chaque script. Vous confirmez que c'est inutile pour vous ?

PS : nous sommes en .net 2.0

Citation:

---

Envoyé par arnolem

Si d'autres peuvent également me donner leur point de vue là dessus, je suis preneur.

En effet, si je dois supprimer toute cette couche de l'application, je ne voudrais le faire de manière sur.

Voici plus de détails sur le fonctionnement.

1. Un Thread infinie ouvre X connexions en base et les stocks dans un pool de connexion
2. Chaque script demande une connexion et la rend dès qu'il a fini
3. Dès que le Thread infinie détecte que toute les connexions sont utilisées, il ajoute Y connexions de plus dans le pool

Tout cela ce fait dans le but d'économiser le temps d'ouverture de connexion à chaque script. Vous confirmez que c'est inutile pour vous ?

PS : nous sommes en .net 2.0

---

Je persiste et je signe :mrgreen:
http://aspalliance.com/1099_Understa...ing_in_NET.all

Citation:

---

Envoyé par lutecefalco

Je persiste et je signe :mrgreen:
http://aspalliance.com/1099_Understa...ing_in_NET.all

---

Merci, C'est ce que je voulais entendre ;) Je vais regarder tout ça.

Si d'autre on des avis à me donner, n'hésitez pas :ccool:

Totalement d'accord, c'est inutile, comme je l'ai dit plus haut une connexion ca s'ouvre avant une requete ou un groupe de requetes, et ca se ferme après. Le framework se charge d'optimiser la liaison à la base de données, ce n'est pas à toi de le faire. Ceci étant dit le fait de garder une connexion ne posera pas de problème de performance. Par exemple une fois j'avais une application qui faisait exclusivement des traitements SQL lourds et garder la meme connexion pendant 30 minutes ou 1 heure, ca marche sans problème. Le risque de saturation du nombre de connexions au serveur, je ne sais pas, j'imagine que ca dépend de l'appli et de comment elle est utilisée, mais pour les perfs le serveur ramera ni plus ni moins que si tu ouvrais et fermais les connexions.

je dirais donc que ce qui a été fait est certes inutile, mais en meme temps est ce que ca vaut le coup de passer du temps à changer ce fonctionnement si au final ca marche? A toi de voir.

Une connexion ouverte en permanence c'est soit un goulot d'étranglement soit une saturation du serveur SQL.

Mettons une connexion ouverte pour un site.
Un internaute arrive à l'instant "t" et provoque le déclenchement d'une requête qui prend 2 secondes.
Un autre internaute arrive à t + 1s. Et déclenche la même requête.
=> Sa requête sera mise en attente le temps que la précédente finisse.

Mettons qu'une nouvelle connexion est créée.
Si 500 internaute arrivent en même temps (vente flash, impôts, ...), le nombre de connections dépasse la taille du pool.
On augmente la taille du pool jusqu'à 4000 connections.
5000 internautes arrivent (publication de la photo de Ribery en fâcheuse posture avec une (très) jeune fille blonde).
=> le nombre de connections au serveur SQL dépasse le nombre par défaut. La base de données plante pendant deux minutes.

Moralité:

• Ouvrir tard, fermer tôt.
• Ce qui n'est pas utilisé doit être détruit.
• Utiliser les objets "Disposable" dans des "using".
• Plutôt que de poser 36 fois la même question à la base de données, mettre en cache, faire des variables publiques statiques (tout de suite bien typées).
• En FW2.0, faire une belle DAL.
• Garder un oeil sur les compteurs de performance de Windows (comprendre les pics de connexion).
• Faire des petites requêtes SQL. Le jour où pour gagner du temps d'exécution on rognera sur le temps d'établissement de la connexion c'est qu'on fera la chasse aux microsecondes.
• Utiliser la Trace pour savoir où gagner du temps.
• Utiliser le planificateur de tâches pour lancer des scripts de mise à jour.

A+

Merci beaucoup pour toute ses belles parôles, je prends note et je vais réfléchir à tout cela a tête reposée. Si je lance des actions, je vous laisserais un petit message pour vous en informer. ;)