Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[HF C/S] chute dramatique des performances

10 réponses
Avatar
Sam
Bonjour,

Une application a été basculée de "HyperFile Classic" vers "HyperFile
Client/Serveur". Globalement pas de changement majeurs, ça fonctionne
pas trop mal en production.

Globalement, mais certains traitement voient leurs performances
s'écrouler de manière dramatique. Par exemple avec strictement les mêmes
données ont passe de 21 minutes pour du "HF Classic" à plus de 4H
(minimum on a arrêté) en "HF C/S".

Il y a plusieurs cas, mais on se focalisant sur un traitement bien
précis il a été démontré que ce n'est pas un pb d'environnement. En
récupérant les données de production pour faire tourner ça sur une
machine de développement on constate également des lenteurs incroyables.

Dans l'environnement de dev, le serveur et le client sont sur la même
machine, pas de passage via le réseau. Jouer sur la taille du cache n'a
pas d'impact important. Passé quelques centaines de Mo l'augmentation
n'a plus aucun effet sur les performances. Aussi bien l'environnement de
prod que celui de dev ont largement assez de mémoire.

Les traitements sont principalement à base de "HLitRecherchePremier",
l'utilisation d'index est systématique. Je ne dis pas qu'il n'y a pas
quelques optimisations possibles, mais rien de choquant à première vue.
N'étant pas l'auteur du code en question, ça permet d'avoir un peu de recul.

Il ne semble pas y avoir de dérapage énorme sur des requêtes longues
(parcours complet d'une table volumineuse via un index). Je n'ai pas de
chiffres précis, mais dans le pire des cas on doublerais le temps (c'est
déjà beaucoup, mais ça ne justifie pas le dérapage).

Par contre quand un grand nombre de requête semble impliqué, alors là
l'accroissement semble important. Aucun requête isolée n'est lente, et
dans l'ensemble le traitement avance avec fluidité, mais avec des
performances dramatiquement en dessous de la version "HF Classic".

On parle ici d'une ratio d'au minimum 10x, peut-être bien plus, et je ne
vois rien qui puisse explique de manière flagrante ces temps, et donc où
je pourrais intervenir (si c'est possible...).

Merci d'avance pour vos suggestions.
Sam.

10 réponses

Avatar
Romain PETIT
avait écrit le 18/11/2010 :
Bonjour,



Bonjour,

Une application a été basculée de "HyperFile Classic" vers "HyperFile
Client/Serveur". Globalement pas de changement majeurs, ça fonctionne pas
trop mal en production.


[...]
Par contre quand un grand nombre de requête semble impliqué, alors là
l'accroissement semble important. Aucun requête isolée n'est lente, et dans
l'ensemble le traitement avance avec fluidité, mais avec des performances
dramatiquement en dessous de la version "HF Classic".



As-tu consulté les billets du blog du ST ?

http://blogs.pcsoft.fr/billets.awp?blog=hyperfilesql_performances

Notamment :
http://blogs.pcsoft.fr/post.awp?blog=hyperfilesql_performances&title=optimisations-hyperfilesql-clientserveur-utilisation-requetes-filtres,7,235

A+

--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Avatar
Romain PETIT
Il se trouve que Romain PETIT a formulé :

-> Eviter les HLRP dans une boucle en CS :

http://blogs.pcsoft.fr/post.awp?title=optimisations-hyperfilesql-clientserveur-eviter-les-traitements-type-hlitrecherche-l%92interieur-une-boucle,7,238

--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Avatar
Sam
Merci pour ces pistes.

Je n'ai pas été assez complet dans ma description du problème. L'appli
est en Windev 12, le moteur HF C/S est celui de la version 15. Dans tout
les cas ce sont les dernières versions.

Le coup des requêtes dans les boucles est un classique, en développement
web on fait très attention à ça. Malheureusement on en a, c'est une
extraction assez complexe.

Du coup je me suis concentré sur le pb du HLitRecherchePremier vs.
HExecuteRequeteSQL sur un cas très simple : une itération sur plus de
60000 enregistrement. Surtout que j'étais justement en train de voir du
côté de paramétrages éventuels sur des "pre-fetch" (que je n'ai pas
trouvé). Donc...

17 secondes avec HLitRecherchePremier
17 secondes avec HExecuteRequeteSQL

Là je suis quand même surpris. J'en ai modifié quelques autres là où
c'était simple, rien de visible. Je vais finir par me "petit-suiss'ider"
comme A.C. :/

Bon ben.... j'y retourne...
Avatar
tjfromparis
on a déjà eu :)


- t'as testé l'appli et le moteur HF sur la même machine (sans passer
par le réseau pour les chaines de connections base)
- même test en forçant l'interface réseau dans les chaines de
connections

- le client et le serveur sont sur la même passerelle ?
- désactive l'anti-virus
- sur le serveur : s'il y a 2 cartes réseau, il y a une surcouche qui
fait la répartition de charge entre les deux : désactive une des 2
cartes et le soft en question
- y'avait un KB chez microsoft pour W2003 à ce sujet



On 18 nov, 14:40, "" wrote:
Merci pour ces pistes.

Je n'ai pas été assez complet dans ma description du problème. L'ap pli
est en Windev 12, le moteur HF C/S est celui de la version 15. Dans tout
les cas ce sont les dernières versions.

Le coup des requêtes dans les boucles est un classique, en développem ent
web on fait très attention à ça. Malheureusement on en a, c'est une
extraction assez complexe.

Du coup je me suis concentré sur le pb du HLitRecherchePremier vs.
HExecuteRequeteSQL sur un cas très simple : une itération sur plus de
60000 enregistrement. Surtout que j'étais justement en train de voir du
côté de paramétrages éventuels sur des "pre-fetch" (que je n'ai p as
trouvé). Donc...

17 secondes avec HLitRecherchePremier
17 secondes avec HExecuteRequeteSQL

Là je suis quand même surpris. J'en ai modifié quelques autres là où
c'était simple, rien de visible. Je vais finir par me "petit-suiss'ider "
comme A.C. :/

Bon ben.... j'y retourne...
Avatar
Sam
J'ai testé ça dans divers contextes, aussi bien chez le client que dans
nos bureaux. En local et via le réseau sur les deux sites.

Déjà sur mon propre PC, entre HF "Classic" et "C/S" il y a une
différence de perf. S'il y a beaucoup de requêtes imbriquées dans des
requêtes, là ça dérape complètement.

Si en plus on passe à travers le réseau... ça tourne au cauchemar. Or
l'objectif des évolutions actuelle chez le client est justement d'avoir
des serveurs TSE d'une part (sans data), et des serveurs de données
d'autre part (bases, fichiers, ...).

Sur des traitement interagissant pas mal avec l'utilisateur c'est
invisible, ou à la limite un peu plus lent. Mais dès qu'on fait des
batches lourd, ça n'est plus exploitable.

J'ai fait des essais avec HExecuteRequeteSQL vs HLitRecherche /
HLitRecherchePremier sur des cas plutôt simples, mais prenant entre 10
et 20 secondes selon le contexte (donc permettant de voir une
différence). Gain strictement nul.

Ce n'est pas un problème d'anti-virus, ni à un élément particulier
d'infrastructure, trop de cas de figure très différents ont été testés.

C'est lent parce-que certains traitements ne sont pas adaptés, c'est un
fait, il ne fait pas se voiler la face. Avec un SGBD plus réputé on
aurait certainement aussi sentis quelque chose. Mais j'ai l'impression
que HF C/S (ou son exploitation via Windev) n'est pas très performant
non plus. Il est normal qu'il y ai une latence liée à la gestion C/S, le
transit des infos sur le réseau (ou même d'un process à l'autre sur la
même machine), mais là ça me semble démesuré.

J'ai déjà corrigé des traitements codés avec les pieds sur MySQL(InnoDB)
pour des sites web (requêtes très mal écrités, index manquants, requêtes
inutiles dans des itérations, ...) et dont les conséquences ont été
invisibles pendant longtemps. Ca dépote pas mal. Je me m'attendais pas à
concurrencer ce genre de produit, mais là.... c'est une grosse claque :/

Bref, soit il y a un problème non encore identifié... soit ça sent le
passage forcé à un SGBD. Tant qu'à devoir ré-écrire pas mal de code,
autant faire le grand saut. PostgreSQL sera un bon candidat, à voir ce
que donnerons les tests (je sais qu'avec les accès Natif il peut y avoir
aussi des pièges).

En tout cas merci beaucoup pour les divers conseils des uns et des
autres. S'il y en a d'autres je suis toujours preneur :-)

Sam.



Le 22/11/2010 16:10, a écrit :
on a déjà eu :)


- t'as testé l'appli et le moteur HF sur la même machine (sans passer
par le réseau pour les chaines de connections base)
- même test en forçant l'interface réseau dans les chaines de
connections

- le client et le serveur sont sur la même passerelle ?
- désactive l'anti-virus
- sur le serveur : s'il y a 2 cartes réseau, il y a une surcouche qui
fait la répartition de charge entre les deux : désactive une des 2
cartes et le soft en question
- y'avait un KB chez microsoft pour W2003 à ce sujet


Avatar
phig
Le 23/11/2010 13:04, a écrit :
J'ai testé ça dans divers contextes, aussi bien chez le client que dans
nos bureaux. En local et via le réseau sur les deux sites.

Déjà sur mon propre PC, entre HF "Classic" et "C/S" il y a une
différence de perf. S'il y a beaucoup de requêtes imbriquées dans des
requêtes, là ça dérape complètement.

Si en plus on passe à travers le réseau... ça tourne au cauchemar. Or
l'objectif des évolutions actuelle chez le client est justement d'avoir
des serveurs TSE d'une part (sans data), et des serveurs de données
d'autre part (bases, fichiers, ...).

Sur des traitement interagissant pas mal avec l'utilisateur c'est
invisible, ou à la limite un peu plus lent. Mais dès qu'on fait des
batches lourd, ça n'est plus exploitable.

J'ai fait des essais avec HExecuteRequeteSQL vs HLitRecherche /
HLitRecherchePremier sur des cas plutôt simples, mais prenant entre 10
et 20 secondes selon le contexte (donc permettant de voir une
différence). Gain strictement nul.

Ce n'est pas un problème d'anti-virus, ni à un élément particulier
d'infrastructure, trop de cas de figure très différents ont été testés.

C'est lent parce-que certains traitements ne sont pas adaptés, c'est un
fait, il ne fait pas se voiler la face. Avec un SGBD plus réputé on
aurait certainement aussi sentis quelque chose. Mais j'ai l'impression
que HF C/S (ou son exploitation via Windev) n'est pas très performant
non plus. Il est normal qu'il y ai une latence liée à la gestion C/S, le
transit des infos sur le réseau (ou même d'un process à l'autre sur la
même machine), mais là ça me semble démesuré.

J'ai déjà corrigé des traitements codés avec les pieds sur MySQL(InnoDB)
pour des sites web (requêtes très mal écrités, index manquants, requêtes
inutiles dans des itérations, ...) et dont les conséquences ont été
invisibles pendant longtemps. Ca dépote pas mal. Je me m'attendais pas à
concurrencer ce genre de produit, mais là.... c'est une grosse claque :/

Bref, soit il y a un problème non encore identifié... soit ça sent le
passage forcé à un SGBD. Tant qu'à devoir ré-écrire pas mal de code,
autant faire le grand saut. PostgreSQL sera un bon candidat, à voir ce
que donnerons les tests (je sais qu'avec les accès Natif il peut y avoir
aussi des pièges).

En tout cas merci beaucoup pour les divers conseils des uns et des
autres. S'il y en a d'autres je suis toujours preneur :-)

Sam.



Le 22/11/2010 16:10, a écrit :
on a déjà eu :)


- t'as testé l'appli et le moteur HF sur la même machine (sans passer
par le réseau pour les chaines de connections base)
- même test en forçant l'interface réseau dans les chaines de
connections

- le client et le serveur sont sur la même passerelle ?
- désactive l'anti-virus
- sur le serveur : s'il y a 2 cartes réseau, il y a une surcouche qui
fait la répartition de charge entre les deux : désactive une des 2
cartes et le soft en question
- y'avait un KB chez microsoft pour W2003 à ce sujet






ce que tu dis me semble très étonnant.
Sur nos applications, les _gains_ de performance après passage à hfcs
sont de l'ordre de 30% plus rapide pour hfcs! nous n'utilisons JAMAIS
hlitrecherchepremier, seulement hlitrecherche et des requetes windev
hexecuterequete ...

que dit le profiler ?
Avatar
Daniel
Le 23/11/2010 13:04, a écrit :
J'ai testé ça dans divers contextes, aussi bien chez le client que dans
nos bureaux. En local et via le réseau sur les deux sites.

Déjà sur mon propre PC, entre HF "Classic" et "C/S" il y a une
différence de perf. S'il y a beaucoup de requêtes imbriquées dans des
requêtes, là ça dérape complètement.

Si en plus on passe à travers le réseau... ça tourne au cauchemar. Or
l'objectif des évolutions actuelle chez le client est justement d'avoir
des serveurs TSE d'une part (sans data), et des serveurs de données
d'autre part (bases, fichiers, ...).

Sur des traitement interagissant pas mal avec l'utilisateur c'est
invisible, ou à la limite un peu plus lent. Mais dès qu'on fait des
batches lourd, ça n'est plus exploitable.

J'ai fait des essais avec HExecuteRequeteSQL vs HLitRecherche /
HLitRecherchePremier sur des cas plutôt simples, mais prenant entre 10
et 20 secondes selon le contexte (donc permettant de voir une
différence). Gain strictement nul.

Ce n'est pas un problème d'anti-virus, ni à un élément particulier
d'infrastructure, trop de cas de figure très différents ont été testés.

C'est lent parce-que certains traitements ne sont pas adaptés, c'est un
fait, il ne fait pas se voiler la face. Avec un SGBD plus réputé on
aurait certainement aussi sentis quelque chose. Mais j'ai l'impression
que HF C/S (ou son exploitation via Windev) n'est pas très performant
non plus. Il est normal qu'il y ai une latence liée à la gestion C/S, le
transit des infos sur le réseau (ou même d'un process à l'autre sur la
même machine), mais là ça me semble démesuré.

J'ai déjà corrigé des traitements codés avec les pieds sur MySQL(InnoDB)
pour des sites web (requêtes très mal écrités, index manquants, requêtes
inutiles dans des itérations, ...) et dont les conséquences ont été
invisibles pendant longtemps. Ca dépote pas mal. Je me m'attendais pas à
concurrencer ce genre de produit, mais là.... c'est une grosse claque :/

Bref, soit il y a un problème non encore identifié... soit ça sent le
passage forcé à un SGBD. Tant qu'à devoir ré-écrire pas mal de code,
autant faire le grand saut. PostgreSQL sera un bon candidat, à voir ce
que donnerons les tests (je sais qu'avec les accès Natif il peut y avoir
aussi des pièges).

En tout cas merci beaucoup pour les divers conseils des uns et des
autres. S'il y en a d'autres je suis toujours preneur :-)

Sam.




Bonjour,

qu'entends tu par requêtes imbriquées ?

des jointures ?
des sous requêtes dans la requête ?
des requêtes dans une boucle sur le client qui va déclencher d'autres
requêtes ?

La différence que tu constates entre HF et HF C/S vient surement que
dans le second cas tu satures la mémoire du moteur.

As tu regardé les infos du gestionnaire de tâches de Windows, ou
monitoré ton système avec l'outil performance de Windows?

S'agit-il de requête uniquement de lecture ou tu as des update/insert?

Faire également attention aux paramètres de hsécurité (je ne sais plus
si c'est le nom exact), mais si en HF classique tu commences à sécuriser
un peu les échanges les temps explosent.

Lorsque j'ai ce type de problème je n'hésite pas à reprendre toutes les
requêtes en oubliant ce qui a été déjà fait.

Pour HF C/S il faudrait voir si il existe des outils pour monitorer le
serveur, mais également des outils permettant de connaître le plan
d'exécution des requêtes du type Select EXPLAIN.



--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Avatar
Sam
Je répond en même temps aux deux derniers messages.


Les traitements posant problème sont principalement des lectures.

Par requêtes imbriquées, j'entends "des requêtes dans une boucle sur le
client qui va déclencher d'autres requêtes". Des requêtes très simples à
chaque fois. Initialement c'est comme ça, et forcément ça ne va pas dans
le bon sens ;-)

Du coup pas la peine de s'embêter avec des "explain". Le pb n'est
justement pas là. Requêtes simples, avec index systématiquement.

Saturer la mémoire du serveur ? J'en doute. La base entière, avec ses
indexes pourraient largement tenir en mémoire (en plus du système,
etc...). A ce sujet j'ai joué avec la mémoire allouée aux indexes, on
arrive assez vite à un stade ou l'augmentation n'a plus d'effet. Aucun
problème de ce côté ça n'a pas été négligé.

Initialement j'ai pas mal regardé le comportement des machines client et
serveur sur la production: aucun soucis de CPU, aucun soucis de mémoire,
pas d'accès disques délirant. Pas mal de consommation réseau, mais rien
qui ne soit de nature à saturer en bande passante la liaison (qui ne
semble pas en cause, des copies de fichiers volumineux donne des temps
très correct).

En HF Classique le HSecurité est normalement orienté sécurité (donc pas
performance) sur l'application, mais comme dit ça devrait plutôt jouer
en défaveur de la version Classique. Côté C/S les échanges avec le
serveur ne sont pas cryptées.

Concernant le profiler, il m'indique que c'est HLitSuivant qui est à
priori le plus consommateur (même sur une requête avec
"HExécuteRequêteSQL" et pas "Hlit...") Ceci dit c'est plutôt normal vu
le nombre de fois où cette fonction est appelée. Mais globalement
l'appli passe plus de temps à attendre ses données qu'autre chose.

Ni le client ni le serveur n'ont l'air à genoux, quelque soit le
contexte (production ou divers contextes de test). C'est juste qu'il y a
du temps "perdu". De trop nombreux temps de latences à échanger des données.

Il y a du boulot :-)

Sam.



Bonjour,

qu'entends tu par requêtes imbriquées ?

des jointures ?
des sous requêtes dans la requête ?
des requêtes dans une boucle sur le client qui va déclencher d'autres
requêtes ?

La différence que tu constates entre HF et HF C/S vient surement que
dans le second cas tu satures la mémoire du moteur.

As tu regardé les infos du gestionnaire de tâches de Windows, ou
monitoré ton système avec l'outil performance de Windows?

S'agit-il de requête uniquement de lecture ou tu as des update/insert?

Faire également attention aux paramètres de hsécurité (je ne sais plus
si c'est le nom exact), mais si en HF classique tu commences à sécuriser
un peu les échanges les temps explosent.

Lorsque j'ai ce type de problème je n'hésite pas à reprendre toutes les
requêtes en oubliant ce qui a été déjà fait.

Pour HF C/S il faudrait voir si il existe des outils pour monitorer le
serveur, mais également des outils permettant de connaître le plan
d'exécution des requêtes du type Select EXPLAIN.



Avatar
Daniel
Ok.

Je présume que sous HF sur le serveur tu dois pouvoir recalculer les
stats et réindexer les tables?.



Suivant la volumétrie, je crois que je ferais une copie des données vers
MySQL ou un moteur que je maitrise mieux, et ensuite à partir de ce
moteur dans une requête SQL je remettrais mes données dans des tables
temporaires, afin ensuite de pouvoir en extraire les stats que je veux
avec un miminum de requête.


Combien de go et de nombre de ligne représentent les tables sur
lesquelles tu bosses?







Le 23/11/2010 15:38, a écrit :
Je répond en même temps aux deux derniers messages.


Les traitements posant problème sont principalement des lectures.

Par requêtes imbriquées, j'entends "des requêtes dans une boucle sur le
client qui va déclencher d'autres requêtes". Des requêtes très simples à
chaque fois. Initialement c'est comme ça, et forcément ça ne va pas dans
le bon sens ;-)

Du coup pas la peine de s'embêter avec des "explain". Le pb n'est
justement pas là. Requêtes simples, avec index systématiquement.

Saturer la mémoire du serveur ? J'en doute. La base entière, avec ses
indexes pourraient largement tenir en mémoire (en plus du système,
etc...). A ce sujet j'ai joué avec la mémoire allouée aux indexes, on
arrive assez vite à un stade ou l'augmentation n'a plus d'effet. Aucun
problème de ce côté ça n'a pas été négligé.

Initialement j'ai pas mal regardé le comportement des machines client et
serveur sur la production: aucun soucis de CPU, aucun soucis de mémoire,
pas d'accès disques délirant. Pas mal de consommation réseau, mais rien
qui ne soit de nature à saturer en bande passante la liaison (qui ne
semble pas en cause, des copies de fichiers volumineux donne des temps
très correct).

En HF Classique le HSecurité est normalement orienté sécurité (donc pas
performance) sur l'application, mais comme dit ça devrait plutôt jouer
en défaveur de la version Classique. Côté C/S les échanges avec le
serveur ne sont pas cryptées.

Concernant le profiler, il m'indique que c'est HLitSuivant qui est à
priori le plus consommateur (même sur une requête avec
"HExécuteRequêteSQL" et pas "Hlit...") Ceci dit c'est plutôt normal vu
le nombre de fois où cette fonction est appelée. Mais globalement
l'appli passe plus de temps à attendre ses données qu'autre chose.

Ni le client ni le serveur n'ont l'air à genoux, quelque soit le
contexte (production ou divers contextes de test). C'est juste qu'il y a
du temps "perdu". De trop nombreux temps de latences à échanger des
données.

Il y a du boulot :-)

Sam.



Bonjour,

qu'entends tu par requêtes imbriquées ?

des jointures ?
des sous requêtes dans la requête ?
des requêtes dans une boucle sur le client qui va déclencher d'autres
requêtes ?

La différence que tu constates entre HF et HF C/S vient surement que
dans le second cas tu satures la mémoire du moteur.

As tu regardé les infos du gestionnaire de tâches de Windows, ou
monitoré ton système avec l'outil performance de Windows?

S'agit-il de requête uniquement de lecture ou tu as des update/insert?

Faire également attention aux paramètres de hsécurité (je ne sais plus
si c'est le nom exact), mais si en HF classique tu commences à sécuriser
un peu les échanges les temps explosent.

Lorsque j'ai ce type de problème je n'hésite pas à reprendre toutes les
requêtes en oubliant ce qui a été déjà fait.

Pour HF C/S il faudrait voir si il existe des outils pour monitorer le
serveur, mais également des outils permettant de connaître le plan
d'exécution des requêtes du type Select EXPLAIN.










--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Avatar
Sam
Ré-indexer, calculer les stats... ça ne change rien.

La base fait environ 1Go, les tables concernées vont de quelques
dizaines de lignes à environ 100000. A la louche, je ne détaille pas,
mais l'ordre de grandeur est correct.

A tout hasard j'ai recompilé l'appli en Windev 15 (puisque elle est en
12 actuellement), ça n'apporte rien. Le moteur HF C/S étant dans sa
toute dernière version.

Pour l'instant on va revenir en HF "Classic". Je chercherais quelques
pistes complémentaires avec un peu de recul. Mais d'ici quelques temps
aborder le problème d'un SGBDR (+ modif du code !) sera étudié plus
sérieusement. De toute manière HyperFile C/S était plus une solution
transitoire, à terme ce sera obligatoire (pour d'autres raisons sans
rapport avec le présent problème).

Merci.
Sam.


Le 23/11/2010 16:26, Daniel a écrit :
Ok.

Je présume que sous HF sur le serveur tu dois pouvoir recalculer les
stats et réindexer les tables?.



Suivant la volumétrie, je crois que je ferais une copie des données vers
MySQL ou un moteur que je maitrise mieux, et ensuite à partir de ce
moteur dans une requête SQL je remettrais mes données dans des tables
temporaires, afin ensuite de pouvoir en extraire les stats que je veux
avec un miminum de requête.


Combien de go et de nombre de ligne représentent les tables sur
lesquelles tu bosses?