Discussion :

[zozo66180]

Bonjour,
Je viens vers vous, car je n'arrive pas à trouver de solution à mon problème.
En effet lorsque via mon projet windev j'effectue une requête sur une base de donnée Interbase, le temps de réponse est d'approximativement 6 secondes, que ce soit sur un SELECT ou un UPDATE et je n'arrive pas à savoir pourquoi...

J'ai essayé plusieurs méthodes, SQLConnect avec SQLexec et aussi HOuvreConnexion avec la connexion en paramètre et hsqlexecute(). Mais toujours le même temps de réponse par contre sur une base de données mysql pas de soucis.

Voila si quelqu'un à une idée formidable a me proposer je suis tout ouïe.

Merci d'avance !

[Atsibat]

Bonjour,

Interbase est une base de type fichier comme Acces et Hyperfile SQLLite etc...
MySQL, PostgreSQL, Oracle sont des systèmes de type CS avec une gestion serveur des données.

Il faudrait savoir quelle est la requête (code)
Combien d'enregistrement elle est sensée retourner
Combien de lignes contient le fichier de départ
Quel est le poids du fichier de la base en Mo

+ Un schéma du traitement appliqué aux données ( ne me donnez pas de code juste un algo en pseudo-code)

Ces conditions détertminent l'angle d'attaque le plus pertinent pour ce type de base

Cordialement,

[zozo66180]

Je ne pourrais pas répondre à toutes ces question car je ne connais pas la réponse pour certaine mais je vais faire au mieux !

Pour la requete, 2 différent un SELECT et un UPDATE :

"SELECT * FROM F_APPVRACL WHERE AVL_NUMPAL = %1;"

"UPDATE f_appvracl SET AVL_DESTOCKAGE = 'O' WHERE AVL_DESTOCKAGE = 'N'
AND AVL_NUMPAL = %1;"

Le SELECT me sert unique pour faire une requete test sur la base pour voir si la connexion est toujours disponible.
l'UPDATE n'agit que sur une seule ligne de la table.

Le nombre d’enregistrement retourné : pour le SELECT peu import apres l'execution de la requete je fait un hlitpremier() unique sur une seule donnée de la table pour voir si elle n'est pas vide.
L'UPDATE n'est pas censée retourner quelque chose.

Je viens de faire un count sur la table et elle contient 223003 élément (mais va continuer à s’agrandir !)

La base pèse environ : 709 Mo (même chose va continuer de s'agrandir)

Par contre le schéma du traitement appliqué aux données, je ne sais pas du tout ce que c'est.

[laurent30s]

Je ne pourrais pas répondre à toutes ces question car je ne connais pas la réponse pour certaine mais je vais faire au mieux !

Pour la requete, 2 différent un SELECT et un UPDATE :

"SELECT * FROM F_APPVRACL WHERE AVL_NUMPAL = %1;"

est-il nécessaire que tu rapatries toutes les colonnes avec *
est-ce que AVL_NUMPAL est indexé

"UPDATE f_appvracl SET AVL_DESTOCKAGE = 'O' WHERE AVL_DESTOCKAGE = 'N'
AND AVL_NUMPAL = %1;"

Le SELECT me sert unique pour faire une requete test sur la base pour voir si la connexion est toujours disponible.
l'UPDATE n'agit que sur une seule ligne de la table.

Le nombre d’enregistrement retourné : pour le SELECT peu import apres l'execution de la requete je fait un hlitpremier() unique sur une seule donnée de la table pour voir si elle n'est pas vide.
L'UPDATE n'est pas censée retourner quelque chose.

Je viens de faire un count sur la table et elle contient 223003 élément (mais va continuer à s’agrandir !)

La base pèse environ : 709 Mo (même chose va continuer de s'agrandir)

Par contre le schéma du traitement appliqué aux données, je ne sais pas du tout ce que c'est.

Faux : ce n'est pas parce que tu ne lis que le premier enregistrement du résultat de ta requête que le nombre d'enregistrement qu'elle retourne n'a pas d'importance sur son temps d'exécution. Puisque toutes les données qu'elle retourne vont transiter par le réseau... donc plus elles sont nombreuses plus c'est long...

Si ton select ne sert qu'à vérifier l'état de la connexion, tu devrais le faire sur un tout petit fichier et t'assurant de ne demander en retour qu'une seule rubrique d'un seul enregistrement

Pour le UPDATE assure toi que que AVL_DESTOCKAGE et AVL_NUMPAL soient indexés...

[tatayo]

Bonjour,

Le SELECT me sert unique pour faire une requete test sur la base pour voir si la connexion est toujours disponible.

Dans ce cas une requête bien plus simple fera l'affaire:

Code SQL :

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

1
2
 
select 1 from dual

Aucun accès à aucune table, je ne vois pas plus rapide.

Tatayo.

[DelphiManiac]

Bonjour,

Interbase est une base de type fichier comme Acces et Hyperfile SQLLite etc...

Juste pour information, cette assertion est complètement fausse. Interbase est une base client/serveur au même titre que les autres bases client/serveur.

[Atsibat]

Bonjour,

pour le coup du client serveur ça dépends de la version en fait d'après leur site :

InterBase Desktop Edition est disponible pour Windows. C'est une puissante solution destinée aux applications autonomes mono-utilisateur.

InterBase ToGo est disponible pour iOS, Windows et Mac OS X et fonctionne également en environnement autonome tout en autorisant le déploiement d'applications utilisant directement les DLL du moteur d'InterBase. Ne nécessitant pas l'exécution d'un processus distinct de serveur de base de données, le moteur est exécuté dans l'espace du processus applicatif pour réduire son encombrement au minimum.

IBLite est une nouvelle base de données pouvant être déployée gratuitement et intégrée sous iOS pour fonctionner de façon autonome et autoriser la diffusion d'applications utilisant directement le moteur d'InterBase.

InterBase Server peut connecter à une base de données des centaines d'utilisateurs simultanés. Il fonctionne sous Windows, Linux, Solaris et Mac OS X.

Et à mon avis seule la version InterBase Server est vraiment ce que nous appelons CS...
Pour ce qui est de Hyperfile je dirais que la version CS est en réalité une version SGDB fichier utiisée à la sauce CS mais ça reste du fichier.

Bon dev

[Atsibat]

Bonjour,

pour la requête il faut :

1 SELECT :

Code :

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

"SELECT ID FROM F_APPVRACL LIMIT 1;"

c'est suffisant

2 UPDATE
il faut indexer AVL_DESTOCKAGE si tu fais souvent ce type de requête

Code :

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

1
2
"UPDATE f_appvracl SET AVL_DESTOCKAGE = 'O' WHERE AVL_DESTOCKAGE = 'N'
AND AVL_NUMPAL = %1;"

3
Sinon il faut récupérer les résultats avec la liste des ID

Code :

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

1
2
"UPDATE f_appvracl SET AVL_DESTOCKAGE = 'O' WHERE ID IN (SELECT ID FROM F_APPVRACL WHERE AVL_DESTOCKAGE = 'N'
AND AVL_NUMPAL = %1); "

ce qui va ter permettre de parcourir la table très vite sur l'ID et de ne faire ton update que sur les lignes concernées.

Essaye un peu et dis nous.

Bon dev

[Emmanuel Lecoester]

Pour info pour qu'un HLItPremier fonctionne il faut que le curseur complet ait été lu donc ... le moteur coté WinDev prends du temps pour récupérer cette donnée.

La question que je poserai est :
- quel temps la requete met sur le même PC en passant par un outil de requetage standard ?

Si c'est le même temps => PB serveur ou réseau
Si c'est plus rapide avec le requeteur => PB coté WinDev

[DelphiManiac]

Historiquement, Interbase est une base client/serveur, même la version "embedded" est considéré comme client/serveur, la seule différence étant que le serveur tourne sous la forme de dll et est intégré dans le process parent.

[tatayo]

2 UPDATE
3
Sinon il faut récupérer les résultats avec la liste des ID

Code :

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

1
2
"UPDATE f_appvracl SET AVL_DESTOCKAGE = 'O' WHERE ID IN (SELECT ID FROM F_APPVRACL WHERE AVL_DESTOCKAGE = 'N'
AND AVL_NUMPAL = %1); "

ce qui va ter permettre de parcourir la table très vite sur l'ID et de ne faire ton update que sur les lignes concernées.

A mon avis ça ne change pas grand chose, car il faut de toute façon parcourir la table dans la sous-requête.
Je pense qu'il faut surtout indexer AVL_NUMPAL. En effet AVL_DESTOCKAGE semble entre un booleen (enfin une chaine utilisée comme telle), donc 2 valeurs possibles, alors que AVL_NUMPAL doit être un numérique ou apparenté. Un index dessus sera plus discriminant.

Tatayo.

[DelphiManiac]

Par contre lors de mes essais avec Firebird (fork d'interbase, à la base), j'avais un problème d'énorme lenteur lors de la 1ière requête et uniquement lors de la 1ière. (Je parle de lenteur coté windev, pas coté serveur)

C'étais soit lié au driver OdeDB utilisé, soit à la manière dont Windev s'interface au driver OleDB. Je n'ai pas réussi à localisé, mais ai résolu le problème en lancant une requête fantôme (inutile) dans le code du projet.

[Atsibat]

Code :

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

1
2
"UPDATE f_appvracl SET AVL_DESTOCKAGE = 'O' WHERE AVL_DESTOCKAGE = 'N'
AND AVL_NUMPAL = %1; "

Code :

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

1
2
"UPDATE f_appvracl SET AVL_DESTOCKAGE = 'O' WHERE ID IN (SELECT ID FROM F_APPVRACL WHERE AVL_DESTOCKAGE = 'N'
AND AVL_NUMPAL = %1); "

Je pense que le mieux c'est d'essayer les deux mais à mon avis ça change tout au contraire je pense que la seconde version est beaucoup plus rapide... spécifiquement sur ce type de base mais c'est vrai aussi sur une base hyperfile avec un gros volume de fichier et une requête d'update qui ne concerne qu'une petite partie de ce fichier genre fichier de 500 000 lignes et update sur 20 000 lignes.

(relancer le serveur entre les deux essais car sinon il y a un système de cache qui fausse les résultats )

[tatayo]

Dans les deux cas l'update n'est fait que sur les lignes qui vérifie les critères de la clause WHERE.
Dans l'hypothèse qu'il n'y a pas d'index sur AVL_DESTOCKAGE ni AVL_NUMPAL, mais un sur ID (clé primaire tant qu'à faire).
Dans le premier cas, le serveur parcours la table, et met à jour les lignes concernées.
Dans le deuxième cas, le serveur parcours la table, crée une liste d'ID, puis parcours l'index pour trouver les lignes à mettre à jour.
Dans les deux cas le nombre de lignes de la table mises à jour est le même, et dans les deux cas il faut parcourir la table.
Où est l'optimisation ?

Tatayo.