Discussion :

[Guillaume1958]

Bonjour,

Jusqu’à maintenant j’utilise avec bonheur le simple Hyperfile Classic en réseau sur ma petite structure.

Mais depuis une semaine, j’étudie la version client/serveur pour en évaluer le gain, pour un éventuel développement plus ambitieux.

Pour cadrer mon environnement de test :
- Windev V.12.
- Un PC pour les programmes, un en version Classic, le même en version client/serveur.
- Un autre PC avec les fichiers partagés pour la version Classic et la base Hyperfile client/serveur.

Mes constatations en terme de performances :
- En requête sur 100 000 enregistrements : première surprise : Classic fait jeu égal avec client/serveur.
- Sur une procédure de constitution d’un fichier de travail, le temps utilisé pour 6441x HlitRecherchePremier :
=====> Classic = 751 ms
=====> Client/serveur = 7s 658ms !!!
- Une table sur un fichier filtré, Classic est bien plus fluide…

J’ai pourtant cherché à optimiser : refaire les statistiques d’index, revoir la taille du cache de manta, emploi de « hlimiteparcours » dans HlitRecherchePremier.

Un avis ? Est il normal que Classic surclasse à ce point client/serveur en terme de performances ?

[Bowen]

Mono utilisateur, mono poste ?
Je veux bien que ça marche en test, mais avec plusieurs utilisateurs et des accès concurrents, ça donne quoi ?
Je dis ça sans parti pris, car je n'ai jamais utilisé le classic (ça semble tout à fait déconseillé avec notre structure et une quarantaine de clients).

[Guillaume1958]

Il est vrai que cela concerne peu de postes en même temps. (3 à 4 maxi)
La base est située sur le disque du principal utilisateur de l'application.
Mais cela fait des années que cela fonctionne sans à-coups, avec robustesse et bon temps de réponse.

Ce n'est pas d'hier que cette solution existe chez Windev, elle a de la bouteille !
Après avec une quarantaine de PC, je ne sais pas. Mais pourquoi pas ?


... Mais ce n'est pas là mon propos... Pourquoi Classic si supérieur à client/serveur sur ce simple test ?

[Bowen]

La base est située sur le disque du principal utilisateur de l'application.

Si je comprends bien, tu as une base par utilisateur, pas une seul base sur laquelle tes 3 ou 4 users viennent se connecter de façon simultanée ?
Je pense que le HF Classic ne gère pas les accès concurrentiels efficacement, et peut donc se permettre d'aller plus vite (sans vérif on va plus vite).
Maintenant, pour les délais annoncés, ça me parait un peu long quand même, mais ça doit venir de ton test.
S'il consiste bien à faire 6441 HLitRecherchePremier, il n'y a pas trop de surprise à ça.

Le classic est directement branché sur ton fichier, il déplace son pointeur grâce aux index chargés dans la mémoire de l'application.

Le client serveur n'est pas chargé en mémoire, il est là pour fournir X clients simultanément. L'instruction HLitRecherchePremier retourne donc lire l'index à chaque fois.

La lecture multiple dans le serveur est en effet très gourmande.
La solution normale consiste à effectuer une requête qui lit tes 6441 lignes d'un coup. C'est d'ailleurs la solution employée dans presque tous les
environnements de développement (autres que PCSoft je veux dire).

[Guillaume1958]

Si je comprends bien, tu as une base par utilisateur, pas une seul base sur laquelle tes 3 ou 4 users viennent se connecter de façon simultanée ?

La base est sur un poste utilisateur, mais 3 ou 4 autres utilisateurs peuvent venir se servir de cette base à tout moment sans problème.
Les accès concurrentiels, le blocage de l'enregistrement traité, les étreintes fatales sont gérées.

Le traitement concerné est complexe et les lectures dans les différents fichiers sont dépendants de conditions. Je ne sais pas faire ce traitement autrement, les simples liaisons et jointures ne me suffisent pas.

Mais là n'est pas le sujet... Simplement je constate qu'un accès direct à un enregistrement est bien moins rapide en client/serveur.

D'autre part je constate qu'une simple requête sur 100 000 enregistrements aurait dû enterer la solution Classic et il n'en est rien...

[Guillaume1958]

Finalement je pense que je vais me répondre à moi même

Plus j'y pense plus je crois que cet hyperfile client/serveur est un oignon !
Le coeur est un hyperfile Classic auquel on a rajouté des couches de client/serveur !
La preuve en est que si je fais un bête copier/coller des fichiers client/serveur vers Classic ça fonctionne sans problème.

Donc si je ne fonctionne qu'avec le coeur, j'évite tous les traitements rajoutés... Donc gains de performances vraiment tangible !

Donc Classic reste intéressant, mais quand client/serveur prend le pas ?

[Bowen]

Très simplement, le HF/CS réduit les temps d'échange entre deux postes, et si tu faisais ton traitement complexe sur le serveur (procédure stockée), je pense que tu aurais un temps normal, et surtout constant quel que soit le poste à partir duquel tu l'utilises.

Soit dit en passant, j'ai quelques traitements plutôt complexes et gourmands dans mon appli, mais je ne crois pas avoir où que ce soit 6000 HitRecherchePremier consécutifs. S'ils ne sont pas modifiables, et que tu ne tires pas de bénéfice des autres avantages de HF/CS, tu devrais peut-être rester en classic.
Pour ma part, je ne changerais pas pour les raisons suivantes :

• Connexion de 30 sessions fixes, et 10 PDA.
• Administration avancée (voir les postes connectés, les verrous, transactions bloquées, déconnecter des connexions)
• Connexion d'applications transverses, sans analyse (relevé de l'analyse dynamique, utilisation de procédures stockées assurant un résultat constant dans toutes les applications)
• Sauvegarde
• Possibilité de changer de serveur dans le futur.

Le dernier point va dans ton sens. Je pense en effet que HF/CS est encore un peu jeune (pas testé la version 15), et pas aussi performant que ses gros concurrents (SQL Server, MySQL, et Oracle pour citer ceux que je connais).

[Jannus]

Plus j'y pense plus je crois que cet hyperfile client/serveur est un oignon !

Je pense que tu te trompes complètement.

Chaque "moteur" a son utilité comme on te l'a expliqué.
C'est d'ailleurs expliqué dans l'aide de WinDev où l'on trouve un comparatif très détaillé du fonctionnement des deux "moteurs", des rasions qui font qu'il faut choisir l'un ou l'autre, etc. (cela dit, Bowen t'a expliqué l'essentiel)

[Guillaume1958]

Merci Bowen pour avoir pris le temps de t'intéresser à ma réflexion !

Je m'aperçois ainsi que passer une application en mode client/serveur demande beaucoup plus que simplement passer les fichiers en C/S !

Je pense que je vais continuer à creuser la question car un de ces jours il me faudra peut être redevelopper notre application principale maison qui tourne actuellement sur un vieux mini système IBM.