Discussion :

[Romanops]

Bonjour,

j'ai une application HyperFile C/S et lorsque je fais une requête c'est extrêmement long (je trouve ça d'ailleurs incroyable...)

J'utilise une table fichier (définie par programmation) voici le code d'exécution :

Code :

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

1
2
3
4
5
6
7
8
 
HExécuteRequêteSQL("f",hRequêteDéfaut,"ma requête")
 
ConstruitTableFichier(Table1,"f",taAvecIdAuto)
 
Table1..FichierParcouru = "f"
 
TableAffiche(Table1)

J'ai également un code de trace entre chaque ligne pour savoir d'où vient la lenteur...

"ma requête" correspond la première fois à ce code SQL :

Code :

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

1
2
3
4
5
6
7
8
9
SELECT TOP 500 
	Internot.I0CLEUNIK AS I0CLEUNIK,	
	Internot.NomInt AS NomInt,	
	Internot.PrenomInt AS PrenomInt,	
	Internot.Code_postal_special AS Code_postal_special
FROM 
	Internot
ORDER BY 
	I0CLEUNIK DESC

NB: j'ai un index sur la rubrique "I0CLEUNIK" puisque c'est l'id auto de ma base...

Jusque là tout va bien, l'affichage est instantané...

Par contre si je rajoute une jointure sur la ville :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT TOP 500 
	Internot.I0CLEUNIK AS I0CLEUNIK,	
	Internot.NomInt AS NomInt,	
	Internot.PrenomInt AS PrenomInt,	
	Internot.Code_postal_special AS Code_postal_special,	
	Ville.Ville AS Ville
FROM 
	Ville,	
	Internot
WHERE 
		Internot.IDVille	=	Ville.IDVille
 
ORDER BY 
	I0CLEUNIK DESC

Il met 5 secondes à executer la requête (HExécuteRequêteSQL).

Comment améliorer ce temps de traitement, sachant que je ne connais pas la requête à l'avance (c'est une requête qui est définie par le client)... ?

Merci d'avance !!

Pour info, ma base contient environ 30 000 enregistrements internot et 40 000 enregistrements ville.

[Emmanuel Lecoester]

en théorie : une PK coté ville (index unique non null) et une FK coté internot (index non unique)

[Romanops]

exact ^^

merci pour la précision

[Bowen]

Et 5 secondes c'est rapide pour du HF/CS...
Ce n'est pas un moteur performant dès qu'il fait des jointures.

Dans notre base, les jointures sur des fichiers de 200 000 lignes prennent un temps fou, et la puissance serveur est pourtant là : serveur HF dédié double quad core, disques en RAID5 avec 512 Mo de cache RAID...

Il faut préférer les parcours sur clés (HLitxx), sur un seul fichier, puis pour chaque ligne lire les fichiers dépendants, par d'autres HLit. Là c'est performant. Par contre le code est beaucoup plus long à écrire, et ne peut pas être fait par un utilisateur.

Reste la solution de remplacer le moteur HF.
(Je serais d'ailleurs curieux d'avoir le ressentit de quelqu'un sur un serveur ProstGre)

[analem]

pour gagner en rapidité vous n'avez qu'à relier directement le la table dans l'onglet Liaison avec votre requête, établir la jointure, le parcours et sélectionnez "accès directe" dans l'onglet contenu.
Après cette configuration, vous exécutez la requête puis "tableaffiche", comme ça l'exécution de la requête et l'affichage est en même temps et vous n'airez pas besoin de faire un retour d'information (comme une barre progressive)

[Romanops]

Bowen, merci du conseil, je vais essayer de me connecter avec MySql pour voir si ça va plus vite. Sinon, j'essayerai avec les hlitxxx.

Sinon, est-ce qu'il est possible d'utiliser les hlitxxx et tableajoute dans un thread ? peut-être est-ce une solution... qu'en pensez vous ?


analem, c'est ce que je fais ici, l'exécution de la requête prend 5 secondes.

[Emmanuel Lecoester]

Partant du principe que les indexes sont présents analysons la requete et déduisons ce que fait le moteur :

Code :

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

1
2
3
4
5
6
7
8
9
SELECT TOP 500 
	Internot.I0CLEUNIK AS I0CLEUNIK,	
	Internot.NomInt AS NomInt,	
	Internot.PrenomInt AS PrenomInt,	
	Internot.Code_postal_special AS Code_postal_special,	
	Ville.Ville AS Ville
FROM 	Ville, Internot
WHERE Internot.IDVille	=	Ville.IDVille
ORDER BY I0CLEUNIK DESC

il y a moins de ville que d'internot et en plus on a une jointure sur la PK => utilisation de la ville comme base de parcours.
Donc pour toutes les villes je parcours la table Internot pour trouver mes lignes.
Ensuite je fais le order by sur la PK de Internot (en plus c'est un desc donc parcours de l'index à "l'envers").
Ensuite je filtre les 500.

Questions :
- quel est le temps si on retire le TOP 500 ?
- quel est le temps si on retire le order by ?
- les stats on été recalculées ?
- que donne la requete reecrite :

Code :

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

1
2
3
4
5
6
7
8
SELECT TOP 500 
	Internot.I0CLEUNIK AS I0CLEUNIK,	
	Internot.NomInt AS NomInt,	
	Internot.PrenomInt AS PrenomInt,	
	Internot.Code_postal_special AS Code_postal_special,	
	Ville.Ville AS Ville
FROM 	Ville inner join Internot on Internot.IDVille = Ville.IDVille
ORDER BY I0CLEUNIK DESC

[Emmanuel Lecoester]

Et 5 secondes c'est rapide pour du HF/CS...
Ce n'est pas un moteur performant dès qu'il fait des jointures.

Dans notre base, les jointures sur des fichiers de 200 000 lignes prennent un temps fou, et la puissance serveur est pourtant là : serveur HF dédié double quad core, disques en RAID5 avec 512 Mo de cache RAID...

Il faut préférer les parcours sur clés (HLitxx), sur un seul fichier, puis pour chaque ligne lire les fichiers dépendants, par d'autres HLit. Là c'est performant. Par contre le code est beaucoup plus long à écrire, et ne peut pas être fait par un utilisateur.

Reste la solution de remplacer le moteur HF.
(Je serais d'ailleurs curieux d'avoir le ressentit de quelqu'un sur un serveur ProstGre)

L'écriture sous forme de requetes et bien plus performante en terme d'IO qu'un accès séquentiel et cela est valable aussi pour HF C/S

[Bowen]

L'écriture sous forme de requetes et bien plus performante en terme d'IO qu'un accès séquentiel et cela est valable aussi pour HF C/S

Sur HF/CS c'est sûr que non...

Sur un HF/CS, avec pas mal d'enreg dans la base, une requête avec
une jointure sur 4 tables et quelques critères... faut environ 10 secondes pour le résultat. (tables d'environ 17 000, 40 000, 240 000 et 7 000 lignes)

Si en plus j'ai un NOT IN dans la requête (mon NOT IN est sur la plus grosse table, celle de 240 000 lignes) alors je passe à 20 secondes environ.

C'est le premier moteur que j'exploite avec d'aussi faibles performances.
(les autres, c'était SQL Server, Oracle, MySQL, et Access)

[EDIT]
Précision : ces temps sont ceux de mon portable (Intel double core), pas ceux du serveur décrit plus haut, fort heureusement.
[/EDIT]

[Emmanuel Lecoester]

Sur HF/CS c'est sûr que non...

Sur un HF/CS, avec pas mal d'enreg dans la base, une requête avec
une jointure sur 4 tables et quelques critères... faut environ 10 secondes pour le résultat. (tables d'environ 17 000, 40 000, 240 000 et 7 000 lignes)

Si tu es sur de ton coup, remonte le point au ST

Si en plus j'ai un NOT IN dans la requête (mon NOT IN est sur la plus grosse table, celle de 240 000 lignes) alors je passe à 20 secondes environ.

Le NOT IN n'a jamais été optimisé dans les SGBD, on lui préfère un not exists beaucoup plus performant.

[Bowen]

Le NOT IN n'a jamais été optimisé dans les SGBD, on lui préfère un not exists beaucoup plus performant.

C'est vrai sur tous les autre moteurs, effectivement.
Mais si tu n'as jamais tenté un exists ou un not exists sur HF/CS, tu vas te faire peur. (avec un vrai jeu de données bien sûr, pas avec 100 lignes dans tes tables...)

Pour ma part, pour sortir la liste des commandes dont une partie n'est pas encore livrée, j'ai tenté plusieurs choses :

Code en not in :

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

1
2
3
4
5
6
7
8
9
 
SELECT Commande_ID, Commande_Code
FROM Document
WHERE Document_Type = 3 --3 c'est mes commandes "client"
AND Commande_ID NOT IN (
SELECT CommandeLigne_Commande_ID 
FROM CommandeLigne
WHERE CommandeLigne_CodeLivr = ''
)

Code en not exists :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT Commande_ID, Commande_Code
FROM Document
WHERE Document_Type = 3 --3 c'est mes commandes "client"
AND Commande_ID NOT IN (
SELECT CommandeLigne_Commande_ID 
FROM CommandeLigne
WHERE CommandeLigne_CodeLivr = ''
AND CommandeLigne_Commande_ID = Commande.Commande_ID
)

Code en requêtes multiples :

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

1
2
3
4
5
6
7
8
9
10
11
 
SELECT Commande_ID, Commande_Code
FROM Document
WHERE Document_Type = 3 --3 c'est mes commandes "client"
 
 
SELECT CommandeLigne_Commande_ID 
FROM CommandeLigne
WHERE CommandeLigne_CodeLivr = ''
 
Ensuite, parcours par HLitxx des deux requêtes

(Les vraies requêtes contiennent plus de critères, et plus de tables, par exemple le tiers concerné, des priorités...)

Le temps d'exécution de chacune est assez énorme :
(Tous les champs de ces requêtes sont indexés)
environ 30 secondes pour le not in, plus de 2 minutes pour le exists, et 4 à 5 secondes pour le parcours "manuel")
En fait, d'une façon globale, la requête sur une seule table (avec les bons indexes) est très rapide, les jointures ralentissent, et les not in encore plus.
LE exists est banni de l'application, il ne me sert que lorsque j'ai une requête complexe pour HF/CS à faire, et que je ne peux pas faire autrement.

[mogwai162]

Juste une parenthèse pour dire que dans les cas de temps de réponses élevés il est interessant de penser aux procédures et/ou aux requêtes stockées.

Une requete pour retrouver un enregistremnt dans un seul fichier prenait 8 secondes j'ai fait une procédure stockée et depuis c'est instantané.

[Emmanuel Lecoester]

Code :

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

1
2
3
4
5
6
7
8
SELECT Commande_ID, Commande_Code
FROM Document
WHERE Document_Type = 3 --3 c'est mes commandes "client"
AND Commande_ID NOT IN (
SELECT CommandeLigne_Commande_ID 
FROM CommandeLigne
WHERE CommandeLigne_CodeLivr = ''
)

as-tu tenté

Code :

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

1
2
3
4
SELECT Commande_ID, Commande_Code
FROM Document left outer join  CommandeLigne on  Commande_ID = CommandeLigne_Commande_ID and CommandeLigne_CodeLivr = ''
WHERE Document_Type = 3 --3 c'est mes commandes "client"
and CommandeLigne_Commande_ID is null

çà peut aider parfois

[Bowen]

Non, je ne l'avais pas tenté, et je viens de le faire dans le WDSQL.
Résultat : 44 secondes ! pour la première exec, 3 pour la seconde
(nombre de lignes récupérées : 212)

Note : pour être sûr d'avoir le bon nombre de lignes, il vaut mieux utiliser le distinct

Romanops : on a "un peu" dévié de ton problème initial. est-il réglé ?

[Romanops]

Bonjour, bonjour !

Désolé de pas avoir répondu hier, j'ai fait le bug hunter toute la journée, et voici ma "conclusion" (qui en fait n'en est pas une car je n'ai pas encore résolu le problème)...

Je remets ma requête pour rappeler un peu le contexte

Code :

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

1
2
3
4
5
6
7
8
9
10
11
SELECT TOP 500
  		Internot.I0CLEUNIK AS I0CLEUNIK,
	 	Internot.NomInt AS NomInt,
	 	Internot.PrenomInt AS PrenomInt,
	 	Internot.Code_postal_special AS Code_postal_special,
	 	Ville.Ville AS Ville
 FROM
  	Ville RIGHT OUTER JOIN Internot ON Internot.IDVille	=	Ville.IDVille 
 
ORDER BY
  	I0CLEUNIK DESC

Je suis parti sur un test avec une nouvelle analyse, avec 2 tables (client et ville) pour faire un projet "témoin" un peu comme en chimie.
la requête passait très bien en 5 centièmes de seconde... même avec mes enregistrements (30 000 clients et 40 000 villes).

Le problème s'est alors posé : pourquoi met-elle autant de temps dans mon application à moi ?

J'ai fait une vingtaine de tests avec à chaque fois des modifs dans l'analyse de mon projet pour me rapprocher le plus possible de mon projet "témoin".

Le problème vient d'une liaison entre société et internaute (deux tables de mon analyse). Lorsque je supprime cette liaison, la requête met 5 centièmes de seconde, lorsque je la remets, ça repasse à 6 secondes...

Voilà pour le moment où j'en suis. Je vais envoyer un case à pcsoft et tenter en parallèle de résoudre le problème car je ne peux pas me passer de cette liaison.

Est-ce que j'ai été clair ?

[Emmanuel Lecoester]

@Romanops : tu ne m'as pas répondu à mes question

@Bowen : 3 secondes ! alors heureux

[Bowen]

Le problème vient d'une liaison entre société et internaute (deux tables de mon analyse). Lorsque je supprime cette liaison, la requête met 5 centièmes de seconde, lorsque je la remets, ça repasse à 6 secondes...
[...]
Est-ce que j'ai été clair ?

Oui c'est clair.
Tu n'aurais pas une différence entre tes deux champs par hasard? (type, sous-type, taille, option de l'index...)
Une conversion des données avant la requête ralentit considérablement la requête (et ça c'est valable sur n'importe quel moteur).

[Bowen]

@Bowen : 3 secondes ! alors heureux

Heu non !
44 secondes ! pour la première exec, 3 pour la seconde
Je peux pas considérer que les utilisateurs vont toujours ouvrir les mêmes écrans, et que le moteur se servira du cache!
Le chiffre utile sur une BDD c'est toujours le premier lancement de la requête.
(c'est pour ça qu'il faut pas se planter en l'écrivant)

[Romanops]

@Romanops : tu ne m'as pas répondu à mes question

désolé, j'ai un peu zappé...

- quel est le temps si on retire le TOP 500 ?
C'est le même... top 5, top 500, top 5000 ou sans top, la requête prends le même temps.

- quel est le temps si on retire le order by ?
heu... je ne sais pas, j'ai pas testé, mais le pb ne vient pas de là mais bien de la liaison entre société et internot.

- les stats on été recalculées ?
oui ^^'

- que donne la requete reecrite :
idem... de plus, j'ai besoin aussi des internot n'ayant pas de ville. J'ai donc pris un right outer join (cf ma requête)

Tu n'aurais pas une différence entre tes deux champs par hasard? (type, sous-type, taille, option de l'index...)
Une conversion des données avant la requête ralentit considérablement la requête (et ça c'est valable sur n'importe quel moteur).

J'ai supprimer ma FK et ma liaison, je les ai recréé et maintenant, j'en suis à 5 centièmes. Je vais donc explorer cette piste. Merci, je vous tiens au courant !

[Emmanuel Lecoester]

J'ai supprimer ma FK et ma liaison, je les ai recréé et maintenant, j'en suis à 5 centièmes. Je vais donc explorer cette piste. Merci, je vous tiens au courant !

Cà sent l'index gruyère...