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".
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".
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".
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...
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...
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...
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 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 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
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
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, tjfromparis@gmail.com 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
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
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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?