Discussion :

[nycolas]

Bonjour,

J'ai un logiciel qui permet d'accéder à une base de données en réseau, le réseau pouvant être local ou par internet. Dans le cadre d'un réseau local, c'est ok, mais dans le cas d'une base par internet, ça fonctionne aussi mais les temps de réponses sont très longs. Quand il y a une requête qui me ramène 100 enregistrements, 100 fois il y a un fetch qui est fait et donc 100 fois un accès au serveur distant, ce qui est très très long.

Pour contourner ce problème de lenteur, j'utilise un script PHP sur le serveur distant, qui lui m'exécute ma requête, récupère toutes les lignes de résultat, et me renvoie les 100 enregistrements d'un seul coup. Et c'est énormément plus rapide.

Par contre, je me demandais s'il n'y avait pas une façon de faire ça nativement avec Firebird, afin de dire à la dll de firebird utilisée par mon programme qu'on veut récupérer toutes les lignes et que la dll récupère tout d'un seul coup, et n'attend pas que le programme demande les lignes une par une pour faire les fetch correspondant...

Je ne sais pas si j'ai été assez clair dans mes explications ? Toute réponse est la bienvenue !

Merci,
Nycolas

[TryExceptEnd]

Avec quels composants tu te connecte a Firebird ?

[nycolas]

En fait j'attaque directement la DLL de Firebird, j'utilise donc les API de Firebird... donc je me suis basé notamment sur la documentations "Interbase 6.0 Api Guide" (mais j'utilise la dernière version de Firebird 1.5).

[makowski]

le protocole réseau a été énormément amélioré depuis firebird 2.0 et encore plus avec la 2.1
si dessous un extrait de la liste support de Firebird :

The application using the database has a speed index
calculator; this runs a long series of transactions and allows one to
compare performance. I've included this figure also (lower is better).

Server Speed Index Packets Data (Bytes)
------ ----------- ------- ------------
MySQL5 357 725 121k
FBSS2.0 470 11066 6.5M
FBSS2.1 265 2310 354k

So FB 2.1 is still generating much more traffic than MySQL, but despite
this it manages to out-pace MySQL, unlike FB2.0.

[nycolas]

Merci pour les réponses. Je vais tester avec Firebird 2.1 afin de voir ce que ça donne. Mais le problème n'est pas tellement le volume de données, mais le nombre d'échanges entre le serveur et le client. Dans mon cas, je voudrais que le serveur renvoie tout en une seule fois, au lieu de devoir être sollicité à chaque ligne de résultat.
Je ne maîtrise pas les curseurs, et je me suis demandé s'il pouvait y avoir une solution de ce côté...?
En tout cas dès que j'ai le temps je teste avec Firebird 2.1 et je vous tiens au courant.

[Barbibulle]

D'après les chiffres avancé, fb2.1 échange 5 fois moins que paquets que FB2.0 (qui lui même en échange moins que FB1.5).

Donc la solution que je testerai avant toute chose dans votre cas, c'est fb2.1.

Si les tests sont concluants (merci de nous en informer) vous aurez encore 2 choix possibles à vous d'en déterminer les "pour" et les "contre"...

Soit Migrer sur à Fb2.1 (tout en améliorant aussi d'autres aspects performances et en ayant un outil à jour).

Soit faire un truc maison sachant qu'à long terme ça ne servira plus lorsque vous passerez à fb2.1.

[ddaime]

As tu essayé en utiliant un script php sur le poste client à des fins de test ? Peux tu nous montrer le code que tu utilises.

[nycolas]

Merci à tous pour vos remarques et idées.

J'ai donc fait différents tests. Le poste client est sous XP Pro, le serveur sous Windows 2003 Serveur avec IIS et PHP5. L'accès au serveur se fait par une connexion ADSL.

Avec Firebird 1.5.5 sur le serveur :
100 insertions = 217.500 secondes
requête renvoyant 500 lignes = 1.050 secondes
ouverture d'un "dossier" (plusieurs requêtes et blobs photos) = 10.500 secondes

Avec Firebird 2.1 sur le serveur :
100 insertions = 130.500 secondes
requête renvoyant 500 lignes = 0.810 secondes
ouverture d'un "dossier" (plusieurs requêtes et blobs photos) = 6.800 secondes

En passant par un script PHP sur le serveur, qui exécute la requête en local sur le serveur et renvoie le résultat en HTTP :
100 insertions = 58.080 secondes
requête renvoyant 500 lignes = 0.750 secondes
ouverture d'un "dossier" (plusieurs requêtes et blobs photos) = 3.900 secondes

J'ai aussi essayé d'ajouter pour ceux qui connaissent Zebedee pour crypter/compresser les flux mais ça n'améliore pas les résultats.

Donc ...il n'y a pas photo, Firebird 2.1 est plus rapide que 1.5, mais il vaut mieux encore et de loin passer par un script PHP qui récupère la requête à exécuter, l'exécute en local, récupère le résultat et le renvoie. De plus cela permet l'avantage de ne pas ouvrir de port supplémentaire (puisque du coup je passe par le port HTTP 80 et non par le port 3050 de Firebird) et de n'avoir le serveur Firebird accédé que localement.

Cependant j'avoue être un peu déçu que les performances natives de Firebird ne soient pas meilleures pour un accès distant, et que je doive gérer cela en PHP...

Mais encore une fois, vu que je passe directement par les API Firebird et non par un composant éprouvé, il y a peut-être des subtilités d'accès au serveur que j'ai mal implémentées...

Est-ce qu'il y a par ici des "pros" des API Firebird qui pourraient peut-être m'éclairer ?

Je suis toujours preneur de toutes idées, solutions, tests, etc, sur ce sujet d'accès à un serveur Firebird distant par internet...

[makowski]

la formule 3 tiers est de toutes façons préférable
pour des tas de raisons et nottament de monter en charge
la solution est de faire un serveur d'application
mais moi je ne choisirai pas php pour ça

ps je suis curieux de savoir ce que tu insert et comment tu le fait, parce tes perfs d'insertions ne sont pas bonnes du tout