Discussion :

[GloRex]

Bonjour,

Je souhaite changer la méthode d’accès a notre bdd Postgres, en mettant en place une couche d'accès aux donnée fonctionnant avec la fabrique de classe proposée par Npgsql.

J'ai modifier le machine.config afin d'y ajouter le nouveau provider.
J'ai ensuite créer une classe abstraite

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
public abstract class DbSource : IDisposable
    {
 
        protected DbConnection Connection;
 
        protected DbProviderFactory Factory;
 
        public DbSource()
        {
            String ConnectionString = ConfigurationManager.AppSettings["UseConnectionString"];
            Factory = DbProviderFactories.GetFactory(ConfigurationManager.ConnectionStrings[ConnectionString].ProviderName);
            Connection = Factory.CreateConnection();
            Connection.ConnectionString = ConfigurationManager.ConnectionStrings[ConnectionString].ConnectionString;
            Connection.Open();
        }
 
        public void Dispose()
        {
            Connection.Close();
            Connection.Dispose();
        }
    }

Puis j'ai réaliser une classe d'implémentation avec les méthodes d’accès et de manipulation des données.

Code :

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

1
2
3
4
5
6
7
8
 
public class DDefault : DbSource
{
 
        public DDefault(): base() { }
 
        ... Méthode d'accès
}

Lors des tests de charge une exception est levée: Exception non gérée*: System.Exception: Timeout while getting a connection from pool. Comme si il n'y avait plus suffisamment de connexion disponible dans le pool (Min=10, Max=50). Ce qui me fait penser que le destructeur de la classe de base n'est pas appelé. Dois-je mettre le code suivant dans toute mes classe d'implémentation, ou y a t'il quelques chose d'autre a faire ???

Code :

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

1
2
3
4
5
 
public new void Dispose()
        {
            base.Dispose();
        }

Merci

[WOLO Laurent]

Non, ca ne va rien résoudre le fait de mettre tes disposes partout.
Le problème probable est que ton code ne respecte pas un best-practice simplement,

Toujours ouvrir une ressource couteuse tardivement et la libérer très tôt.

Est ce que tu peux nous faire voir le code de tes tests de charge ?

[GloRex]

Bonjour,

J'ai trouvé une parade qui me permet d'éviter cette exception...
Le thread qui accèdent à la base de donnée sont placés dans le ThreadPool de l'application, j'ai donc limité la taille de ce pool qui par défaut était à 100 (4 cores * 25).

Code :

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

ThreadPool.SetMaxThreads(3, 3);

Si quelqu'un a un exemple sur la manière de générer ce genre d'exception, je suis toujours preneur

[WOLO Laurent]

Non, tu modifies tes conditions de tests pour te satisfaire !

Non essaie de tester ceci :

Code :

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

1
2
3
4
5
6
 
//Toute ta gymnastique ici
Using (DDefault db= new DDefault())
{
     //Execute une requête SQL ici rien d'autre ici
}

Tu devrais améliorer tes performances.

[GloRex]

Bonjour,

effectivement cela na rien résolu, c'est pour ça que j'ai mis en place la solution postée juste après toi. Depuis cette limitation l'application se comporte beaucoup mieux.

Dans notre cas il s'agit principalement de stress test, car il s'agit d'une application gérant des centaines de connexions presque simultanées (à quelque dizaine de seconde près) plusieurs fois par jour.

Script du test (en php):
Le script parcours deux répertoires contenant les données fraîches. Il récupère un identifiant sur les fichiers puis envoie au serveur, via le réseau, un signal respectant 1 protocole établi dans la fonction writesignal().

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
 
<?php
	include_once('./lib/library.php');
	error_reporting(E_ERROR | E_PARSE);
	$filename = getcwd() . '\files\actions.txt';
 
	$mdbDirectory = '../triggers_data/data/mdb';
	$cntDirectory = '../triggers_data/data/cnt';
 
	$DataFileArr = array();
 
	if($dossier = opendir($mdbDirectory))
	{
		while(false !== ($fichier = readdir($dossier)))
		{
			$elem = split("_",$fichier);
			if($elem[0] != "." && $elem[0] != ".." && !in_array($elem[0], $DataFileArr ))
			{
				array_push($DataFileArr, $elem[0]);
			}
		}
	}
	if($dossier = opendir($cntDirectory))
	{
		while(false !== ($fichier = readdir($dossier)))
		{
			$elem = split("_", $fichier);
			if($elem[0] != "." && $elem[0] != ".." && !in_array($elem[0], $DataFileArr ))
			{
				array_push($DataFileArr, $elem[0]);
			}
		}
	}
 
	$timerstart = microtime(true);
	$confirm = new Confirmation();
	$confirm->Action = "SIG";
	$confirm->RetCode = '0';
	foreach ($DataFileArr as &$value) {
		$confirm->SiteNo = $value;
		$rc = controlConfirm($confirm);
		if($rc == '00'){
			//envoie du signal au serveur applicatif
			if (!writesignal($confirm->ToCsv(), $filename)){
				$rc = '-1';
			}
		}
		echo 'SIG FROM ' . $confirm->SiteNo . '    STATUS:' . $rc . '<br>';
	}
        $timerend = microtime(true);
	$script_time = number_format($timerend - $timerstart, 3);
	echo 'Script exécuté en ' . $script_time . ' seconde(s)';
?>

Non, tu modifies tes conditions de tests pour te satisfairte !

Non, mon script de test ci dessus n'a pas changé. C'est la manière dont je gère mes tâches au sein même de l'application qui a changé. Cependant tu as raison, il faut que je change l'ordonnancement des mes actions sur la classe DDefault (ainsi que les autre) afin de libérer la connexion plus vite.

A bientot

[WOLO Laurent]

Est ce que tu as essayé de voir le comportement des compteurs de performances pour obtenir le nombre de requêtes/connexions simultannées ?