Discussion :

[burkan]

Bonjour,

J'ai développé une application de gestion de stock avec Delphi 6. La base de données est sous SQL Serveur. L'ouverture d'un table (TADOTable.Open) qui est lie à une vue (view) de la base de données prend sur mon PC de développement (pour un résultat qui retourne 23000 linges) quelques secondes (2-10 seconds) mais sur le Serveur de production plus de 10 minutes.

voici ci-dessous la requête SQL qui générée la vue:

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
 
SELECT     dbo.CDM.CBCDM, dbo.PRD.Designation, dbo.CDM.CodePRD, dbo.CDM.CodeInventaire, 
                      dbo.CDM.NumSerieCDM, dbo.CLS.LibelleCLS, dbo.CTGR.LibelleCTGR, 
                      dbo.CDM.EtatCDM, dbo.CDM.DateR, dbo.DR.PrixAchatHT, 
                      dbo.FRS.RS AS RSFRS, dbo.CDM.Observation, dbo.DPT.CodeDPT, dbo.DPT.LibelleDPT, 
                      dbo.MGZ.CodeMGZ, dbo.MGZ.LibelleMGZ, dbo.CMPT.LibelleCMPT, dbo.RYN.LibelleRYN, 
                      dbo.ETGR.LibelleETGR, dbo.TM.LibelleMVT AS MvtR, dbo.CDM.NumR, 
                      TM_1.LibelleMVT AS MvtSRT, dbo.SRT.NumSRT, dbo.SRT.DateSRT, dbo.SRT.LibelleNV, 
                      dbo.PRT.RS AS RSPRT, dbo.R.TypeR, dbo.SRT.Agent AS AgentSRT, 
                      dbo.R.Agent AS AgentR, dbo.CDM.CDMStatut, dbo.CDM.DatePeremption, 
                      dbo.CDM.PrixUnitaireR, dbo.CDM.QuantiteStock, dbo.CDM.QuantiteR
FROM         dbo.FRS RIGHT OUTER JOIN
                      dbo.DRC INNER JOIN
                      dbo.R INNER JOIN
                      dbo.DR ON dbo.R.NumR = dbo.DR.NumR INNER JOIN
                      dbo.TM ON dbo.R.TypeR = dbo.TM.TM ON 
                      dbo.DRC.NumR = dbo.DR.NumR AND 
                      dbo.DRC.CodePRD = dbo.DR.CodePRD LEFT OUTER JOIN
                      dbo.PRT ON dbo.R.CodePRT = dbo.PRT.CodePRT ON 
                      dbo.FRS.CodeFRS = dbo.R.CodeFRS RIGHT OUTER JOIN
                      dbo.DS INNER JOIN
                      dbo.DSC ON dbo.DS.NumSRT = dbo.DSC.NumSRT AND 
                      dbo.DS.CodePRD = dbo.DSC.CodePRD INNER JOIN
                      dbo.SRT ON dbo.DS.NumSRT = dbo.SRT.NumSRT INNER JOIN
                      dbo.TM AS TM_1 ON dbo.SRT.TypeSRT = TM_1.TM RIGHT OUTER JOIN
                      dbo.ETGR RIGHT OUTER JOIN
                      dbo.CDM ON dbo.ETGR.CodeETGR = dbo.CDM.CodeETGR LEFT OUTER JOIN
                      dbo.CLS INNER JOIN
                      dbo.SC ON dbo.CLS.CodeCLS = dbo.SC.CodeCLS INNER JOIN
                      dbo.CTGR ON dbo.CLS.CodeCTGR = dbo.CTGR.CodeCTGR RIGHT OUTER JOIN
                      dbo.PRD ON dbo.SC.CodeSC = dbo.PRD.CodeSC LEFT OUTER JOIN
                      dbo.MRQ ON dbo.PRD.CodeMRQ = dbo.MRQ.CodeMRQ ON dbo.CDM.CodePRD = dbo.PRD.CodePRD ON 
                      dbo.DSC.CBCDM = dbo.CDM.CBCDM AND 
                      dbo.DSC.NumR = dbo.CDM.NumR ON 
                      dbo.DRC.CBCDM = dbo.CDM.CBCDM AND 
                      dbo.DRC.NumR = dbo.CDM.NumR LEFT OUTER JOIN
                      dbo.RYN ON dbo.ETGR.CodeRYN = dbo.RYN.CodeRYN LEFT OUTER JOIN
                      dbo.CMPT ON dbo.RYN.CodeCMPT = dbo.CMPT.CodeCMPT LEFT OUTER JOIN
                      dbo.MGZ ON dbo.CMPT.CodeMGZ = dbo.MGZ.CodeMGZ LEFT OUTER JOIN
                      dbo.DPT ON dbo.MGZ.CodeDPT = dbo.DPT.CodeDPT

J'ai eu le même problème de lenteur sur un autre PC qui tourne sous Windows7 avec SQL Serveur 2008.

Voici un résume de temps d'exécution de la même requête avec la même quantité de données :

Developpement (laptop HP): Windows XP-SP3 + SQL Server 2005 : 2-6 secs
Developpement (laptop HP): Windows XP-SP3 + SQL Server 2008 : 2-6 secs
Teste (laptop Acer): Windows 7 + SQL Server 2008 : plus de 12 minutes
Production (Server HP): Windows 2003 server + SQL Server 2005 : plus de 12 minutes

Je suis vraiment bloqué à cause de ce problème de lenteur .

Merci d'avance pour votre aide.

Cdt,
Burkan

[Népomucène]

Je suis assez surpris du nombre de relations entre les tables (ou vues) de la requête.
Si j'ai bien compté il y en a 29

Dans une gestion de stocks, le nombre de lignes par table est assez important.
Pas étonnant que la requête soit lente ...
Je suis aussi très étonné qu'une gestion de stock nécessite plus d'une dizaine de tables.

Bon. J'arrête là. Deux possibilités pour accélérer les réponses :

Plan A) Revoir le modèle de données (trop de tables ?) avec quelques bons index.
Mais pour cela, je suppose que c'est trop tard.

Plan B) Passer par des tables temporaires (dans le cadre d'une procédure stockée) :
1) On crée plusieurs requêtes ne comprenant que 2 ou 3 tables uniquement sur les données qui nous intéressent (condition WHERE).
Cela permet d'optimiser individuellement les jointures avec la clause "WITH INDEX".
2) Le résultat de chaque requête est placé dans une table temporaire distincte.
3) On fait une requête sur les tables temporaires ainsi créées (qui comportent nécessairement beaucoup moins de données et donc beaucoup plus rapide).
4) La procédure stockée renvoie le résultat.

Sur une base assez grosse (30 Go) avec des tables de plusieurs millions de lignes,
j'arrive à avoir des résultats en moins d'une seconde dans l'analyseur de requête (SQL Server 2000)

[burkan]

Bonjour Népomucène,

La requête prend mois de 2 sec dans SQL Serveur Studio Manager et mois de 6 seconds avec mon application et Windows XP SP3, et plus de 12 minutes avec mon application (le même exécutable) et Windows 2003 Serveur.

Pour moi la requête est assez (ou presque) optimisée. peut être que le problème est dans l'application elle même. mais la question est:

est ce normal d'avoir deux temps d'exécution complètement déferrent pour la même application sur deux systèmes déférents ? je note que l'application est compilé avec Delphi6 sous Windows XP.

Merci d'avance pour ton aide.

Cdt,
Fouad

[Népomucène]

Oui, j'ai souvent vu des différences assez importante d'un système à l'autre.

Cependant, passer de 6 secondes à 12 minutes est tout de même exceptionnel.

Combien de temps met la requête sur le serveur Windows 2003 en utilisant SQL Serveur Studio Manager ? (pour faire la différence avec l'application)

[Ptit_Dje]

Quel est l'execution plan de la requete en production ?

[burkan]

bonjour Népomucène;

temps d'execution avec SQL Serveur Studio Manager sur le serveur 2003 = 2-6 secs

Cdt,
Burkan

[burkan]

Bonjour,

J'ai essai de remplacer la vue par une requête SQL en utilisant TADOQuery, mais la requête prend toujours plus de temps avec Windows 2003.

J'ai remarqué que dans Windows 2003 le CPU est occupé à plus de 97% par SQL Serveur pendant le temps d'exécution de la requête (plus de 12 min).

tj le même problème, la même version de SQL Serveur (Express), le même exécutable & la même base de données (les fichiers sont copies du poste de développement vers me serveur de production) mais je n'arrive pas à expliquer pour quoi le temps d'exécution est beaucoup plus important sur un serveur (Windows 2003) et un poste XP.

Merci d'avance pour l'aide.

Cdt,
Fouad

[hmira]

bonjour Népomucène;
temps d'execution avec SQL Serveur Studio Manager sur le serveur 2003 = 2-6 secs
Cdt,
Burkan

Donc, si je comprends bien, et d’après la description que tu en fais, le problème ne provient pas de SQL Server, le problème provient bien de l’application qui tourne sur le serveur Windows 2003.

Remarques :

- Les problèmes posés par les applications développées sous Delphi 6 ou Delphi 7.1, tournant sous Windows 2003 sont largement connus et évoqués dans les forums ..
La plus part sont corrigés par l’application des patches officiels ou non officiels ! En effet, certains développeurs chevronnés, proposent par exemple des modifications de l’unité SysUtils pour corriger des bug des modules CGI développés sous Delphi, et tournant sous Windows 2003.
Ces patches concernent généralement les unités suivantes :
SysConst.pas
System.pas
SysUtils.pas
VarUtils.pas
Variants.pas

- Le site pour télécharger les patches Delphi est le suivant :
http://cc.embarcadero.com/reg/delphi

PS :
* Il faut être un utilisateur enregistré pour pouvoir télécharger les patchs,
* Le site ne propose aucun patch pour Delphi 6 ! (cela ne veut pas dire qu’il n’y a pas eu dans le temps, des patchs pour Delphi 6 !).
* La plus ancienne version de Delphi pour la quelle le site propose des patches est Delphi 7.1

Quelques pistes pour résoudre le problème :

- Essayer pour ce traitement en particulier d’utiliser les composant dbExpress en lieu et place des composants ADO... (en effet, il se peut très bien que le problème provienne des composants ADO qui communiquent aux travers des objets COM/DCOM).
- Migrer l’application vers Delphi 7.1 En effet, cette version des très stables et beaucoup de mise à jour, patch, ressources etc. sont disponibles pour cette version.
- Même, si le problème sera résolu sous Delphi 7.1, il faudra tout de même revoir l’application, en effet ouvrir un TADOQuery pour retourner vers le poste client (ou vers le serveur applicatif) 23 000 lignes est une complète aberration. En effet, soit il s’agit de traitement, et auquel cas, ce dernier doit être effectué au niveau du serveur de base de données par une procédure stockée, soit il s’agit de l’affichage des enregistrements (page par page), et au quel cas il faut absolument utiliser la "technique de la pagination" pour ne ramener par exemple que 20 ou 30 enregistrements à la fois.

A+

[burkan]

Bonjour hmira,

Merci bcp pour ton aide,
J'ai remplacé le composants ADO par des composant dbExpress et le résultat est 5 sec .
J'ai même essai de migrer vers Delphi 7 mais j'ai eu le même problème de performance.

Pour l'instant je vais garder la version Delphi 6 et je remplace les composants ADO par dbExpress.

Pour l'idée de pagination, une nouvelle version est encours de développement.

Merci encore une fois pour l'aide Hmira, Népomucène et Ptit_Dje.

Cdt,
Fouad

[WOLO Laurent]

Merci de penser au bouton résolu.