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

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/08/2010, 11h47
zinzineti

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

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.
03/08/2010, 10h12
zinzineti

Bonjour,
Je renouvelle ma demande.
03/08/2010, 12h28
dbaffaleuf

- 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.
03/08/2010, 13h37
mikedavem

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#)

++
03/08/2010, 15h43
zinzineti

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.

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

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

06/08/2010, 21h07
mikedavem

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.

++
06/08/2010, 22h53
SQLpro

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 +
06/08/2010, 23h24
zinzineti

Citation:

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

Citation:

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
07/08/2010, 06h54
mikedavem

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+

Citation:

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:

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+

09/08/2010, 10h18
SQLpro

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

A +
09/08/2010, 10h55
mikedavem

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).

++
09/08/2010, 11h34
zinzineti

Citation:

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)

Citation:

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
09/08/2010, 11h41
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.
09/08/2010, 11h42
mikedavem

Si je reprends ton 1er post :

Citation:

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.

++
09/08/2010, 11h46
zinzineti

Citation:

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.
09/08/2010, 12h03
mikedavem

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 .. :ccool:

++

Citation:

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:

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:

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

Citation:

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:

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:

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 ;)

Voir 40 message(s) de cette discussion en une page