Discussion :

[dbaffaleuf]

La réponse est là:

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

Ce n'est pas une histoire de login, c'est une histoire de requêtes. Si tu as 3 connexions (avec le même login ou pas peu importe) qui exécutent chacune un UPDATE ou un DELETE sur la même table avec les mêmes critères, la première va obtenir le latch et les autres vont attendre. Et si tu as 150 connexions qui font la même chose c'est pareil. Tout est sérialisé, parce que toutes tes connexions sont en attente exactement sur la même ressource. Il faudrait que chaque connexion utilise des requêtes différentes avec des prédicats différents pour verrouiller des lignes différentes, et permettre à plusieurs connexions de travailler en même temps sur des jeux de données différents. C'est pour ça que faire un outil de charge en Transact est compliqué, il faut un jeu d'APIs plus riche pour pouvoir simuler une vraie activité.

Le nombre maximum de requêtes simultanées est cappé par max worker threads de toutes façons. Et en général, on ne l'atteint pas.

HTH. David B.

[zinzineti]

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

Est ce que la mise en attente volontaire de l'exécution de la requête (voir script ci-dessous) peut participer à mieux stresser le système au-delà de la contention des sessions ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
SET NOCOUNT ON
DECLARE @START  INT, @STOP INT
SET  @START=0 ;  SET @STOP = 1000 -- Nombre de transactions SELECT
WAITFOR DELAY '00:00:05'   -- Mise en attente volontaire de requête 
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

[dbaffaleuf]

Non ce qui doit changer à chaque exécution c'est :

Code :

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

SELECT TOP 100 id_nom,nom FROM MaBase.dbo.MaTable

Il faudrait par exemple une connexion qui fasse un UPDATE, une qui fasse un DELETE, une qui fasse un INSERT, plusieurs qui fassent des SELECT, + sur d'autres tables dans ton modèle. Il faut un référentiel de requêtes à exécuter, pour que chaque connexion vienne piocher la requête suivante et l'exécute, exactement comme dans SQL Server. Il faut un tableau de tâches à exécuter, un timer, un pool de threads, un objet de synchronisation... Et Transact ne peut pas t'apporter ça.

David B.

[zinzineti]

Alors là .. il faut que je regarde alors du côté .NET. (c'est ce que mikedavem a proposé au début)
En tout merci pour toutes ces explications.
Je vois mieux ce qu'il faut faire maintenant.
Je vous tiens au courant de la suite...
Thanks

[zinzineti]

Rapidement j'ai trouvé ce lien : DBstressUtil
Avec un exemple de script SQL préparé sous SQL 2000

Code :

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

1
2
3
4
5
6
7
8
9
10
-- Sample of "test script" for DBstressUtil, to be submitted on the NORTHWIND database
EXEC CustOrdersDetail @OrderID=10281
EXEC CustOrdersDetail @OrderID=10282
EXEC CustOrdersDetail @OrderID=11077
SELECT * FROM Orders
SELECT * FROM Orders ORDER BY CustomerID
SELECT * FROM Orders ORDER BY CustomerID DESC
EXEC CustOrderHist @CustomerID='ROMEY'
EXEC CustOrderHist @CustomerID='OLDWO'
EXEC CustOrderHist @CustomerID='HUNGO'

Je pense l'utiliser avec mes script SQL 2005/2008

Qu'en pensez-vous ?

Merci

[dbaffaleuf]

A première vue ça a l'air pas mal.

David B.

[zinzineti]

Hello Men
Rapidement pour vous tenir au courant de la suite.

Pour un test basic :

0.) j'ai modifié le code source de DBstressUtil pour afficher les millisecondes pour le format date heure dans le fichier log.csv

1.) J'ai préparé le fichier commands.txt qui contient :

Code :

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

1
2
SELECT * FROM MaBase.dbo.MaTable
UPDATE MaBase.dbo.MaTable SET Nom = 'SQLSERVER' WHERE ID >= 10 AND ID <= 100

2.) J'ai fixé le nombre de "Client instances" = 2 (Deux threads)
et gardé les autres valeurs (Interval et execution schift) par défaut

Voici le résutat

DateHeure | Instance |Nb commande |Durée (ms)
-------------------------------------------------------------------
08/10/2010 12:15:31.276 | 1 | 1 |1218,7578
08/10/2010 12:15:31.948 | 2 | 1 |1578,1351
08/10/2010 12:15:32.589 | 1 | 2 | 312,502
08/10/2010 12:15:33.214 | 2 | 2 |265,6267

Analyse
=======
Pour chaque requête (du fichier commands.txt) :
- les Threads ne sont pas lancés au même moment [ heuresement ]
- l'ordre de traitement est toujours Thread 1 puis Thread 2,

Etape suivante
===========
- Préparer mes series de requêtes pour le fichier d'entrée (commands.txt)
- collecter les indicateurs de performances
- puis analyse

En tout cas merci à tous pour vos contributions pour ce post.
Un grand MERCI aux deux David (dbaffaleuf et mikedavem)

A+