Discussion :

[Magnus]

Bonjour,

Je reprends une application en mode standalone d'environ 80 000 lignes écrite sous Intraweb & Delphi 7 qui accède à une base ORACLE 9i.

Mon GROS problème est que cette application est très lente : même pour accéder à une table vide.
Je cherche donc à améliorer les performances de manière significative et la plus rapide possible (c'est-à-dire ne pas réécrire le projet).

Pour cela, on m'a déjà conseillé de :
- passer du mode standalone vers une architecture client / (web) serveur
- tester éventuellement un autre driver de connexion à la base de données (lequel ?)

Qu'en pensez-vous ? Est-ce que les performances vont être améliorées à coup sûr ?
D'autant que je ne sais absolument pas comment faire fonctionner un serveur web que ce soit pour configurer Apache, IIS ou migrer une application standalone en librairie ISAPI. Est-ce difficile / coûteux en temps ?

Merci d'avance de vos conseils.

[skywaukers]

bonjour,

je ne pense pas que le fait de passer de standalone en isapi change énormément les temps de réponse, à moins que le pc sur lequel tourne l'application aujourd'hui soit une bourrique. Les composants d'accès ont peut-être des comportement différents, encore qu'ils doivent tous passer par OCI je suppose, dopnc cela ne soit pas non plus expliquer.
Je pense qu'il faudrait plutôt regarder dans le code, il soit y avoir des choses à optimiser, parce qu'interroger une table vide, même avec le plus mauvais driver, cela ne doit pas être lent.

@++
Dany

[Magnus]

Merci de prendre de jeter un coup d'oeil par ici Dany,

...à moins que le pc sur lequel tourne l'application aujourd'hui soit une bourrique

il faut que je demande au client mais apparemment il s'agit de "PC standards" avec des proc ~1 GHz & 256 - 512 Mo de RAM je pense.

Je pense qu'il faudrait plutôt regarder dans le code, il soit y avoir des choses à optimiser, parce qu'interroger une table vide, même avec le plus mauvais driver, cela ne doit pas être lent

je suis d'accord avec toi mais hormis les ordres SQL il y a bien des optimisations à faire en plus, non ?
D'autant que les performances sont moyennes voire mauvaises pour tous les traitements alors que la complexité de certains traitements est enfantine (donc optimisation au niveau des ordres SQL quasi nulle).

Je vais récupérer les données du client et faire plus de tests afin de déterminer si les performances sont diverses ou au contraire plutôt uniformes.
Je te tiens au courant des résultats.

[Magnus]

En faisant pas mal de recherches sur internet et en paramétrant mon application intraweb, j'ai pu comprendre :
- qu'un serveur web peut améliorer les performances de mon application dans le cas d'une grande volumétrie de requêtes,
- les composants utilisés dbExpress ont des performances parmi les meilleures (apparemment les composants DAO sont peut être légèrement plus efficaces)

Conclusion : comment optimiser mon application de manière significative ?
J'en suis à rechercher des profiler pour mesurer les appels de chaque procédure et je pense me trouver assez vite à court d'idées.

Merci par avance.

[Magnus]

J'ai récupéré les données du client en question histoire d'évaluer la lenteure globale.
Conclusion : l'affichage d'une quelconque fiche nécessite 6 à 15 secondes sur mon PC (bi-proc de 3 GHz avec 1 Go de RAM).

Pour moi l'optimisation des requêtes SQL ne peut pas être la seule réponse à ce problème général étant donné :
- la simplicité de certaines fiches (nombre de composants, traitements effectués au chargement de la fiche, etc.)
- la puissance de mon PC (à la différence du client)
- le type des requêtes SQL concernées : en général de simples SELECT ... FROM ... WHERE ... sans UNION, CASE, IN, EXISTS, etc.
- l'efficacité des composants d'accès à la base de données (dbExpress)
- l'uniformité des mesures de performances quelles que soient les fiches.

En revanche, ton message m'a donné une idée : je vais créer un projet ULTRA simplifié accédant à la même base de données avec les mêmes composants / drivers.
Le but de ce projet sera de mettre en avant le temps de chargement des différents types de composants TIWDBAdvGrid, TIWCombobox, etc.

J'afficherais mes résultats pour ceux / celles que çà intéresse ou qui veulent me filer un coup de pouce

[MarcP]

Comment sont gérées les connections à la base ?
En effet, pour peu que la connection soit cryptée, le lancement de la liaison est tres long.
Il faut te connecter à la base lors du lancement de l'appli, une fois pour toute, puis partager cette connection. Si tu lances une connection sur chaque fiche, le délai ne me parait pas abbérant

[Magnus]

pour peu que la connection soit cryptée, le lancement de la liaison est tres long

Ok mais comment savoir si ma connection est cryptée, je ne vois rien dans les propriétés du TSQLConnection ? Où trouve-t'on cette info ?

Il faut te connecter à la base lors du lancement de l'appli, une fois pour toute, puis partager cette connection

C'est exactement la configuration actuelle ça fait donc une optimisation possible en moins

Merci pour ton coup de main.

[MarcP]

pour peu que la connection soit cryptée, le lancement de la liaison est tres long

Ok mais comment savoir si ma connection est cryptée, je ne vois rien dans les propriétés du TSQLConnection ? Où trouve-t'on cette info ?

Il faut te connecter à la base lors du lancement de l'appli, une fois pour toute, puis partager cette connection

C'est exactement la configuration actuelle ça fait donc une optimisation possible en moins

Merci pour ton coup de main.

Pour le cryptge c'est dans tes paramètres de connection, comme le user/password. Ca depends de la abse, des composants, etc
Sinon ne te creuse pas la tete, fais une seule connection et tes perfs s'envoleront
Regarde ensuite tes durées de requetes (pour ma part je loggue les accès bases pour les chronometrer), mais ca doit etre raisonnable.

[Magnus]

Pour le cryptge c'est dans tes paramètres de connection, comme le user/password. Ca depends de la abse, des composants, etc

Je n'ai pas d'infos de cryptage dans les propriétés de la connexion

Sinon ne te creuse pas la tete, fais une seule connection et tes perfs s'envoleront

C'est déjà la configuration que j'ai, donc je vais pas pouvoir optimiser grand chose de ce côté là.

Regarde ensuite tes durées de requetes (pour ma part je loggue les accès bases pour les chronometrer), mais ca doit etre raisonnable.

Je vais calculer ces durées et je posterai les résultats.

[Magnus]

Concernant les temps d'exécution des requêtes : la plupart des requêtes concernées prennent entre 0 et 15 ms mais il en existe une qui nécessite environ 190 ms.
Cette dernière requête effectue un :

Code :

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

1
2
SELECT DISTINCT CI_RS1
FROM PR0300;

Mon premier réflexe a été de vérifier que la colonne CI_RS1 est bien indexée et c'est le cas.
Finalement est-ce que ce temps est raisonnable ? Enorme ?

Conclusion actuelle : pour une fiche qui nécessite environ 6 secondes pour s'afficher totalement, voici les traitements qui prennent du temps par ordre décroissant :
- plusieurs passages de la propriété Active du DataSet à True : de 320 à 1 300 ms
- la requête précédente : 190 ms
- <les composants IntraWeb eux-mêmes ?> : le reste du temps soit :
6 000 - (320 + 1 300 + 190) = 4 190 ms soit plus de 4 secondes passées à faire quoi ?

Je vais encore poser la même question mais où mon application perd elle du temps ?
Please

[MarcP]

ce temps est raisonnable.
C'est l'établissement de la connection qui doit ramer.
Regarde comment c'est fait...

[Magnus]

ce temps est raisonnable.
C'est l'établissement de la connection qui doit ramer.
Regarde comment c'est fait...

Si tu parles de passer la propriété Connected de mon TSQLConnection à True alors je ne le fais qu'une seule fois donc mes fiches ne seraient pas continuellement lentes à s'afficher.

J'ai quand même effectuer le calcul avec la fonction GetTickCount qui mesure alors ~400 ms.

[MarcP]

Sans ton code dur de t'aider + ...
Place des fonctions pour tracer ton code un peu partout, jusqu'a voir ce qui rame... je peux rien te dire de mieux
Sinon, recode une mini appli qui fait juste un connect et liste une table en copiant collant, voir si c'est réellement la abse qui rame

[skywaukers]

bonjour,

non, les compos intraweb ne sont pas lents, je les utilisent perso sans aucun soucis. j'ai même remplacé l'annuaire de la société qui était écrit en JSP et j'ai des temps de réponse meilleurs avec le même nombre d'user, donc pas de soucis de ce côté à mon avis. Côté BDD j'ai jamais essayé avec Oracle, mais il n'y a pas de raison.
le mieux c'est de refaire une mini appli qui accède à ta BDD.
Regarde peut-être aussi du côté du port utilisé par intraweb, dès fois qu'il serait utilisé par une autre applis.

@++
Dany

[Magnus]

Sans ton code dur de t'aider + ...

Ok, je vais essayer de faire un "condensé".

non, les compos intraweb ne sont pas lents, je les utilisent perso sans aucun soucis. j'ai même remplacé l'annuaire de la société qui était écrit en JSP et j'ai des temps de réponse meilleurs avec le même nombre d'user

Je peux me tromper mais les tests que j'ai passés des heures à effectuer tentent à prouver que la lenteur est causée par les composants eux-mêmes.

Remarque : j'aurais dû mieux m'exprimer : l'application utilise essentiellement des composants Intraweb payants de la société TMS dont des TIWDBAdbWebGrid, TIWRegion, TIWCombobox, TIWLabel, etc.
Pour moi, ce sont ces composants TMS qui ralentissent l'application.
Comme je n'ai pas trouvé d'article mesurant les performances de ces composants, c'est justement ce que je tends à prouver actuellement : les performances sont-elles meilleures / pires avec des composants Intraweb "classiques" ?

BDD j'ai jamais essayé avec Oracle, mais il n'y a pas de raison

Pour moi ça ne peut pas venir d'Oracle dans la mesure où :
- les index sont présents lorsque nécessaires
- le temps moyen pour effectuer une requête de sélection + ou - élaborée et récupérer le résultat dans Delphi varie entre 0 - 15 ms.

Regarde peut-être aussi du côté du port utilisé par intraweb, dès fois qu'il serait utilisé par une autre applis

J'utilise un programme nommé Active Ports qui (comme son nom l'indique ) permet de visualiser les ports ouverts. Là encore pour moi il n'y rien à améliorer de ce côté.

Merci de vos participations et j'attends avec impatience vos prochaines remarques.

[MarcP]

Hum, j'utilise les composants TMS moi aussi et ils sont très rapides.
Sinon, lance Ethereal.
ca va te permettre de sniffer tout ce qui sort par le réseau, ca te donneras surement de bonne réponses.... (et en +, c'est gratuit...)

[Magnus]

Merci de sortir mon post des oubliettes.

Ton message me rassure et m'inquiète en même temps : d'après tous mes posts sur tous les forums, mon application est optimisée à tous les niveaux :
- Oracle : OK
- dbExpress : OK
- driver dxexpoda.dll : OK
- Intraweb : OK
- TMS : OK
- mode standalone : OK

Je me note dans un coin d'utiliser Ethereal que j'ai déjà manipulé sous Unix (je suis actuellement sous XP Pro).

Ceci dit, j'ai 2 questions suite à ton post :
1/ tu n'aurais pas paramétré d'une quelconque manière ces composants TMS (quelle version utilises-tu, j'ai essayé les v2.0.1.0 / 2.6.0.0 ?)
2/ quelle paramétrage, erreur de conception générale, etc. implique une telle LENTEUR dans mon application ?

[MarcP]

TMS : je mets à jour tous les 6 mois. Ce soir je reinstalle ma bécane de dev avec les dernières versions
Pour moi cette lenteur c'est celle qu'on a souvent sur les grosses bases pendant la creation de la connection, mais ca, quel que soit le système ou le language.
Tu devrais installer Ethereal, ca se fait en 10mn (ca marche AUSSI sous windows) et un simple lancement de ton appli te dira de suite ou ca merde.
genre si des le lancement ou le clic sur un bouton tu vois du traffic, tu peux attendre la réponse, voir ce qui met du temps, ou meme te rendre compte que tu fais un SELECT * oublié dans un coin
Et ensuite tu viens raconter ce qui rame, ca commence à m'intriguer

[Magnus]

J'apprends à utiliser Ethereal et voici mes 1er résultats.

Pour l'instant j'ai constaté que ma machine et le serveur de bases de données échangent beaucoup de trames (?) de cette manière :
source / destination / protocol / info
192.168.0.102 / 192.168.0.5 / TNS / Request, Data(6), Data
192.168.0.5 / 192.168.0.102 / TNS / Response, Data(6), Data

Pour récupérer ~2000 lignes d'une seule table, j'ai sniffé ~520 couples de trames successives et strictement identiques au couple ci-dessus.

Comme j'ai lancé la capture avant la connexion à la base de données, ce n'est peut être pas surprenant.
Je vais faire des tests en lançant Ethereal après avoir ouvert la connexion à la base de données.

Comment analyser efficacement le trafic sur le réseau vu le nombre de paquets échangés ?
Je dois rechercher un protocole, une adresse réseau, etc. précise ?

Qu'en penses-tu ?

[MarcP]

disons que c'est dur de savoir ce qui crée ce traffic.
Essaie de couper les autres services reseau (partage de fichiers, etc), de ne pas naviguer, rien qui puisse parasiter
Puis lance ton soft, et désactives les procédures jusqu'a trouver ce qui cloche