Test de montée de charge sous SQL 2K5/2K8

**zinzineti** · 02/08/2010, 11h47

Bonjour tout le monde

Je suis entrain de rechercher un outil pour faire des tests de monter de charge sous SQL 2005 ou SQL 2008. Sous SQL 2000 il existe un outil de test de monter de charge nommé DATABASE HAMMER fournit par Microsoft. Mais sous 2005/2008 rien de tel n'est fournit.

Pour mon test j'ai besoin de simuler :

1.) des connexions simultanées (environ 100 connexions simultanées) sur le serveur de base de données

2.) pour chaque connexion, exécuter de façon aléatoire des requêtes : SELECT, INSERT, UPDATE en se basant sur une table initialement remplit avec des données significatifs

3.) Collecter des compteurs de performances (pour ça, il n'y a pas de problème. je m'en sortir avec PerfMon)

OS = W2K3

Merci d'avance.

**zinzineti** · 03/08/2010, 10h12

Bonjour,
Je renouvelle ma demande.

**dbaffaleuf** · 03/08/2010, 12h28

- Dans Profiler 2008, capturer une trace avec le template de replay, et la rejouer ensuite avec plusieurs threads.
- Se faire son propre outil.

David B.

**mikedavem** · 03/08/2010, 13h37

Bonjour,

Je crois que Quest Software propose un outil de ce genre mais payant ..
Sinon même chose que dbaffaleuf, SQL Profiler ou un outil maison (perso j'en ai fait un en C#)

++

**zinzineti** · 03/08/2010, 15h43

Merci pour vos réponses.
L'idée est d'arriver à définir les pré-requis pour une application transactionnelle :
-- Mémoire Minimale
-- Caractéristiques minimales CPU
-- Nombre maximale d'utilisateurs simultanés
-- ...

Je continue de creuser le sujet.

**zinzineti** · 06/08/2010, 15h43

Je pensais simuler des connexions multiples et simultanées d'utilisateurs avec les commandes :

Code :

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

1
2
3
4
5
sqlcmd -S "myInstance" -U "user1" -P "pwduser1" -d "mybase" -i "E:\Test_Charge\fichierSQL.sql" -o "E:\Test_Charge\Sortie\user1.txt"
 
sqlcmd -S "myInstance" -U "user2" -P "pwduser2" -d "mybase" -i "E:\Test_Charge\fichierSQL.sql" -o "E:\Test_Charge\Sortie\user2.txt"
 
....

Mais je constate dans les fichiers de sortie que la commande lancée par user1 se termine d'abord avant le lancement de celle de user2. Bref pas de multithreading avec sqlcmd ?!

Pensez-vous qu'on peut simuler les connexions multiples et simultanées à SQL Server avec un langage de scripting ? je pense à Powershell ou ...

Merci d'avance

**mikedavem** · 06/08/2010, 21h07

Si tu lances tes scripts sqlcmd à la suite dans un batch, tu n'auras effectivement qu'une exécution séquentielle de sqlcmd.

Pour ce qui est de powershell, oui c'est possible mais je trouve qu'il est beaucoup plus facile de développer ce genre de programme avec un langage .NET qu'avec un langage de scripting comme powershell.

++

**SQLpro** · 06/08/2010, 22h53

Vous pouvez lancer plusieurs fenêtre cmdshell simultanément et les faire boucler. Cependant cela ne remplacera jamais ce que peuvent faire différents robots de test !

A +

**zinzineti** · 06/08/2010, 23h24

Envoyé par SQLpro

Vous pouvez lancer plusieurs fenêtre cmdshell simultanément et les faire boucler.
A +

Merci SQLPro pour cette idée. Je vais l'essayer

Envoyé par SQLpro

Cependant cela ne remplacera jamais ce que peuvent faire différents robots de test !
A +

Justement parlant de robot il me semble que Visual Studio Team System 2008 permet de faire ce genre des tests de charge. Avez-vous un retour d'expérience à ce sujet ?

Merci d'avance

**mikedavem** · 07/08/2010, 06h54

Oui cette édition de vs propose en effet cette fonctionnalité. J'ai déjà vu certains dev l'utiliser. Je n'ai jamais pris le temps de tester moi même.

A+

**zinzineti** · 08/08/2010, 19h41

Envoyé par SQLpro

Vous pouvez lancer plusieurs fenêtre cmdshell simultanément et les faire boucler.
A +

Oui ça marche

Voici comment j'ai procédé :

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
DECLARE @CMD NVARCHAR(4000) -- Commande Shell à exécuter
        , @SERVER VARCHAR(255)	   -- Nom de l'instance
	, @LOGIN VARCHAR(255)	       -- Utilisateur
	, @PWD VARCHAR(255)	           -- Mot de pase
	, @NbExecutions INT            -- Nombre de fois où la requête est exécutée
	, @FICHIERSQL NVARCHAR(255)	   -- Nom du fichier contenant la requête à exécuter
	, @FICHIERSORTIE NVARCHAR(255) -- Nom des fichiers de sortie
 
BEGIN	
SET @SERVER = 'monInstance'
SET @LOGIN ='monLogin'
SET @PWD = 'monPwd' 
SET @NbExecutions = 2
SET @FICHIERSQL = 'E:\Test_Charge\fichierSQL.sql'
SET @FICHIERSORTIE = 'E:\Test_Charge\Sortie\Log%i.txt' 
 
SET @CMD = 'For /L %i in (1,1,' + CONVERT(VARCHAR,@NbExecutions) + ') do start sqlcmd -S "'+ ISNULL(@SERVER,'') + '" -U "'+ISNULL(@LOGIN,'')+'" -P "'+ISNULL(@PWD,'')+'" -i "' + ISNULL(@FICHIERSQL,'')+'" -o "' + ISNULL(@FICHIERSORTIE,'')+'"'
--PRINT @CMD
EXEC master..xp_cmdshell @CMD
END

Et mes fichiers de sortie indiquent une exécutions simultanées (au millisecondes près).
Nombre d'utilisateurs simulés ici 2.
Vos commentaires sont les bienvenus

A+

**SQLpro** · 09/08/2010, 10h18

Bien !!! Je crois même que je vais piquer ton script....

A +

**mikedavem** · 09/08/2010, 10h55

Le script est bien mais je vois un inconvénient majeur à celui-ci :

Le lancement de plusieurs threads sqlcmd avec la même procédure stockée ou requête implique que tous tes utilisateurs "virtuels" accèdent au même jeu de données, ce qui peut causer des verrous intempestifs et une situation irréaliste. En faisant l'analogie avec la poste, cela reviendrait à mettre tout le monde sur un même guichet ... forcément une file d'attente va se créer et il est probable que d'autres guichets resteront libres .. ce qui est dommage ..

De plus lancer une multitude de sessions SQLCMD n'est peut être pas la meilleure solution car une session sqlcmd consomme déjà un son propre espace de mémoire (1 Mo environ). Est ce qu'une simple connexion ADO ne serait pas une solution plus viable dans ce cas ? (Je n'ai pas testé pour comparer pour le moment donc je ne m'avance pas trop).

++

**zinzineti** · 09/08/2010, 11h34

Envoyé par mikedavem

Le lancement de plusieurs threads sqlcmd avec la même procédure stockée ou requête implique que tous tes utilisateurs "virtuels" accèdent au même jeu de données, ce qui peut causer des verrous intempestifs.
++

C'est justement l'accès concurrent aux données que je souhaite tester, afin :
1. ) de définir le nombre maximal d'utilisateurs simultanés, en prenant en compte le délai d'attente maximale estimé à 5 secondes.
2.) d'identifier les bons niveau d'isolation dans les transactions (dans les requêtes)

implique que tous tes utilisateurs "virtuels" accèdent au même jeu de données, ce qui peut causer des verrous intempestifs et une situation irréaliste.

Je n'ai pas bien compris en quoi cette situation est irréaliste ?

Tu peux me donner plus de détails ?

Merci d'avance

**dbaffaleuf** · 09/08/2010, 11h41

Parce que dans la réalité tous les utilisateurs accèdent aux mêmes tables mais pas exactement aux mêmes lignes. Il faudrait variabiliser l'accès, jouer sur les prédicats etc, sans quoi il y aura toujours une connexion en exécution et les autres en attente (sauf si tous les verrous sont partagés), qu'il y ait 2 , 10 ou 100 connexions dans ta boucle.

David B.

**mikedavem** · 09/08/2010, 11h42

Si je reprends ton 1er post :

Pour mon test j'ai besoin de simuler :

1.) des connexions simultanées (environ 100 connexions simultanées) sur le serveur de base de données

2.) pour chaque connexion, exécuter de façon aléatoire des requêtes : SELECT, INSERT, UPDATE en se basant sur une table initialement remplit avec des données significatifs

3.) Collecter des compteurs de performances (pour ça, il n'y a pas de problème. je m'en sortir avec PerfMon)

Le script que tu as fait ne répond pas à ce que tu désires faire réellement. Si ton but est de faire de la concurrence d'accès pourquoi pas mais XXX users qui utilisent les mêmes données aux mêmes moments ne reflète pas la réalite d'une part et ce n'est pas un test de stress ou de charge au sens premier du terme d'autre part.

++

**zinzineti** · 09/08/2010, 11h46

Envoyé par mikedavem

En faisant l'analogie avec la poste, cela reviendrait à mettre tout le monde sur un même guichet ... forcément une file d'attente va se créer et il est probable que d'autres guichets resteront libres .. ce qui est dommage ..
++

Ah ... je n'avais pas vu ton commentaire avant de faire ma réponse.
Alors les autres guichets libres, représentent quoi ?
des ressources disponibles ?

L'objectif c'est de stresser à fond le système, puis de voir sa réaction.

**mikedavem** · 09/08/2010, 12h03

Oui c'est exactement cela.

Le problème de ton script c'est qu'il ne pas va "stresser" ton serveur de la bonne façon car il va se concentrer en un seul point qui sera certainement le point de contention avec des sessions en attente.

Ton idée de départ n'est pas mauvaise mais il faudrait peut être changer la façon d'appeler les requêtes avec différents paramètres comme le suggère dbaffaleuf etc ... ce n'est qu'une piste évidemment ..

++

**zinzineti** · 09/08/2010, 12h07

Envoyé par mikedavem

Si je reprends ton 1er post :
Le script que tu as fait ne répond pas à ce que tu désires faire réellement. Si ton but est de faire de la concurrence d'accès pourquoi pas mais XXX users qui utilisent les mêmes données aux mêmes moments ne reflète pas la réalite d'une part et ce n'est pas un test de stress ou de charge au sens premier du terme d'autre part.
++

Voici comment je pensais procéder pour mes tests de montée de charge :
1.) Simuler les connexions multiples et simultanées d'ulisateurs.
Script à utiliser

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
DECLARE @CMD NVARCHAR(4000) -- Commande Shell à exécuter
        , @SERVER VARCHAR(255)	   -- Nom de l'instance
	, @LOGIN VARCHAR(255)	       -- Utilisateur
	, @PWD VARCHAR(255)	           -- Mot de pase
	, @NbExecutions INT            -- Nombre de fois où la requête est exécutée
	, @FICHIERSQL NVARCHAR(255)	   -- Nom du fichier contenant la requête à exécuter
	, @FICHIERSORTIE NVARCHAR(255) -- Nom des fichiers de sortie
 
BEGIN	
SET @SERVER = 'monInstance'
SET @LOGIN ='monLogin'
SET @PWD = 'monPwd' 
SET @NbExecutions = 2
SET @FICHIERSQL = 'E:\Test_Charge\fichierSQL.sql'
SET @FICHIERSORTIE = 'E:\Test_Charge\Sortie\Log%i.txt' 
 
SET @CMD = 'For /L %i in (1,1,' + CONVERT(VARCHAR,@NbExecutions) + ') do start sqlcmd -S "'+ ISNULL(@SERVER,'') + '" -U "'+ISNULL(@LOGIN,'')+'" -P "'+ISNULL(@PWD,'')+'" -i "' + ISNULL(@FICHIERSQL,'')+'" -o "' + ISNULL(@FICHIERSORTIE,'')+'"'
--PRINT @CMD
EXEC master..xp_cmdshell @CMD
END

2.) Déclencher pour chaque user des transactions (SELECT, INSERT, DELETE).
Ces transactions seront codées dans le fichier fichierSQL.sq utilisé par le script ci-dessus.
Voici un bout de code pour un des SELECT

Code :

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

1
2
3
4
5
6
7
8
9
10
11
SET NOCOUNT ON
DECLARE @START  INT, @STOP INT
SET  @START=0 ;  SET @STOP = 1000 -- Nombre de transactions SELECT
WHILE (@START < @STOP) 
BEGIN
BEGIN TRAN
SELECT SUSER_NAME() + ' # ' + CONVERT(VARCHAR(12), GETDATE(), 114) 
SELECT TOP 100 id_nom,nom FROM MaBase.dbo.MaTable
SET @START = @START + 1
COMMIT TRAN
END

3.) Analyser les compteurs de perf

Est que cette démarche peut être considérée comme un test de montée en charge ? Suis-je en dehors de ce qu'il faut faire ?

Merci d'avance pour vos réponses

**zinzineti** · 09/08/2010, 12h21

Envoyé par dbaffaleuf

Parce que dans la réalité tous les utilisateurs accèdent aux mêmes tables mais pas exactement aux mêmes lignes. Il faudrait variabiliser l'accès, jouer sur les prédicats etc, sans quoi il y aura toujours une connexion en exécution et les autres en attente (sauf si tous les verrous sont partagés), qu'il y ait 2 , 10 ou 100 connexions dans ta boucle.
David B.

Si je comprends bien, au lieu d'utiliser le même login/pwd dans les sqlcmd tu proposes d'utiliser différents login/pwd ?
Autrement dit à la place de :

Code :

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

1
2
3
4
 
SET @LOGIN ='monLogin'
SET @PWD = 'monPwd'
SET @CMD = 'For /L %i in (1,1,' + CONVERT(VARCHAR,@NbExecutions) + ') do start sqlcmd -S "'+ ISNULL(@SERVER,'') + '" -U "'+ISNULL(@LOGIN,'')+'" -P "'+ISNULL(@PWD,'')+'" -i "' + ISNULL(@FICHIERSQL,'')+'" -o "' + ISNULL(@FICHIERSORTIE,'')+'"'

il faut quelque chose qui ressemble à

Code :

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

1
2
3
4
 
SET @LOGIN ='monLogin%i'
SET @PWD = 'monPwd%i'
SET @CMD = 'For /L %i in (1,1,' + CONVERT(VARCHAR,@NbExecutions) + ') do start sqlcmd -S "'+ ISNULL(@SERVER,'') + '" -U "'+ISNULL(@LOGIN,'')+'" -P "'+ISNULL(@PWD,'')+'" -i "' + ISNULL(@FICHIERSQL,'')+'" -o "' + ISNULL(@FICHIERSORTIE,'')+'"'

Ai-je bien pigé ?

Merci les gars

Test de montée de charge sous SQL 2K5/2K8

Administration SQL Server

Discussions similaires

Partager

Partager