Discussion :

[Creenshaw]

Suite à la migration de plusieurs applications utilisant des composants BDE vers ADO, j'ai constaté une très nette augmentation des temps de réponses de ces applications.

Après quelques tests de comparaisons entre les 2 types de composants, j'ai pu constater qu'au mieux j'obtenais sur certaines requêtes (Type SELECT) une perte de temps d'un ratio de 5 :
ex :
qryX en (BDE) TQuery = 60ms environ
qryX en (ADO) TADOQuery = 300ms environ

En ayant joué sur les paramètres tels :
- CursorLocation : gain important lorsque on position le curseur en clUseServer (non applicable a toutes les requêtes)
- Prepared : aucun effet notable lorsqu'il est positionné à true
- CursorType et LockType : ctStatic et ltReadOnly gain très faible par rapport aux autres

Ne voyant pas d'autre gain possible au niveau des composants, j'aimerai savoir si vous aviez d'autres piste d'optimisation, car les utilisateurs ne se satisfaisent pas de ces temps (et c'est chiant un utilisateur ! )

[Rayek]

Optimiser les requetes.
Genre :
- Eviter les "select *" et préférer "Select champ,champ1, ..."
- Préférer des inner join à des table.id=Table2.id dans la close where
- Bien indexé correctement les tables
- etc ...

[Creenshaw]

De ce que j'ai vu jusqu'a présent, c'est plutôt correct de ce coté là aussi

[Rayek]

De ce que j'ai vu jusqu'a présent, c'est plutôt correct de ce coté là aussi

Le problème peut venir aussi que tu passes par un ODBC, donc que ca rajoute une couche. tu aurais un gain de temps avec un fournisseur oledb correspondant a ta base de données (queltype d'ailleur ?)

[Frank]

Cet excellent tutoriel peut peut être t'aider

[Creenshaw]

Cet excellent tutoriel peut peut être t'aider

Déjà lu Ca d'ailleur été le premier doc que j'ai lu à ce sujet. Très bien fait d'ailleurs ca il explique clairement une bonne partie des paramétrages des composants ADO.

Sinon j'ai une base Oracle9i Enterprise Edition Release 9.2.0.3.0

Une piste que j'ai peut être trouvée (c'est bête de pas avoir commencé par là d'ailleurs), un patch de correction pour Delphi 6

Area: database\ado
Reference Number: 115042
Status: Fixed in Delphi 6 Update Pack
Date Reported: 7/10/01
Severity: Commonly Encountered
Type: Minor Functionality Failure
Problem:
Opening a ADOquery in Delphi 6 is much slower then it was in Delphi 5 because of extra calls to the F.Properties for "every" field in the RecordSet regardless of the "already" determined FieldType.

Je teste mes temps d'accès avec ça demain et je vous tiens au courant

[Rayek]

Vu que tu utilises ADO et oracle, je pense que tu dois utiliser le "Microsotf ole db provider for oracle. Si mes souvenir sont bon celui fourni de base est pas terrible, il faudrait voir si tu peux pas installé ceux de ta version d'oracle, a mon avis ca aiderai grandement en gain de vitesse.

[rtoutain]

+1

[Frank]

Puisque tu utilises une base Oracle, pourquoi ne pas utiliser les composants dbexpress ?

[Creenshaw]

Qques news :

L'installation du correctif pour D6 apporte un plus mais vraiment très minime. Par rapport à mon cas d'exemple, une vingtaine de ms seulement.

Par contre l'installation des composants MDAC 2.7 (j'étais en 2.5) à diviser mes temps d'accès par 2. (140 ms)..

mais je reste toujours très loin de BDE et ce n'est pas suffisant pour les utilisateurs

@ Malatar : je vais faire des recherches de ce coté là merci
@ Frank : je n'ai pas eu le choix de la techno employée

++

[Creenshaw]

J'ai installé les Oracle Provider for OLE DB fourni avec la partie cliente de ma version d'Oracle et ai reconfigurer mes composant TADOConnection
Résultats : catastrophe

Sur la même requête que précedement je suis repassé à des temps de 635ms.

<désespéré>

[Rayek]

Fait un essai avec les drivers ODBC, tu n'es plus a ca pret maintenant. Autant tu auras un mieux.
Puis passe avec le MDAC 2.8, ca pourrait arranger encore un peu (ou l'inverse )

[Creenshaw]

Passez directement par les pilotes ODBC ca donne des temps monstrueux, genre 5 secondes pour l'exécution d'une requêtes... c'est ptête moi qui me suis gouré dans le paramétrage, mais ayant fait ça avec un collègue ayant plus de connaissance que moi sur le sujet, ce que nous avons fait m'a semblé correct.

Pour la MDAC 2.8, j'ai testé aussi, mais vu les correctifs concernant ADO (très peu) de cette version, c'est normal que ça n'est rien changé.

Bientôt on pourra lire sur les murs de mon bureau :
ADO m'a tuer

[Rayek]

Sinon tes tests de temps, tu les as réalisé comment et avec combien de données dans la table ?

[Creenshaw]

Avec une requête extraite d'un serveur d'application. Elle est interéssente car contient plusieurs jointures.

Sinon j'ai créé une petite appli qui sur demande, créé un nouveau thread, paramètre le composant ADO utilisé (ADOQuery ou ADODataset) en fonction des besoin de l'utilisateur.
CursorLocation
Prepared
CursorType
Temps de pause
LockType

Et sur un TTimer ma form principale interroge chaque thread créé et leur demande le temps min / max / moyen / nb d'itérations.

Coté thread, chacun à un composant ADOConnection indépendant, ainsi qu'une ADOQuery / ADODataset
Je chope l'heure/min/sec avant Open et après Open, puis calcule la différence pour savoir quel est le temps d'éxécution

Je pourrais te mettre la requête mais ca va pas te parler bcp
Jointure entre 3 tables avec comme table principale, une qui contient environ 17000 enregistrements)