|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Base de données WINDEV 5.0 lente |
| Débuté par MZBARADAI, 18 juin 2004 00:24 - 3 réponses |
| |
| | | |
|
| |
Posté le 18 juin 2004 - 00:24 |
Une compagnie nous a développé une base de données lente ! J'ai posé 3 questions
aux développeurs qui m'ont répondu. Moi-même, je ne suis pas informaticien,
j'aimerais bien avoir l'avis ou l'analyse des développeurs chevronnés concernant
la réponse des développeurs de notre application.
Voici les 3 questions et réponse et mercis d'avance.
Q1. Pourquoi le processeur ne travaille pas à 100% quand on demande une liste
d'inventaires dans La base de données ? Une job qui prend 2h quand le processeur
roule
à 50% devrait prendre 1h si le processeur roulait à 100% de ses capacités
!
Est-ce que c'est le "design" de la base de données qui ne permet pas de profiter
de la
capacité du processeur ?
R1. Le design de La base de données n'est en rien responsable du taux d'occupations
CPU de votre serveur.
Cette gestion est plutôt du domaine du système d'exploitation du serveur,
et
éventuellement de l'outils de développement utilisé pour La base de données.
Dans le cas de La base de données il s'agit de WinDev 5.5 qui était normalement
optimisé pour tourner sur des postes Windows 95, Windows 98 ou Windows NT
4.
La façon dont le CPU sera utilisé lors de l'utilisation d'une application
développé avec cette plate-forme reste l'entière responsabilité de la
compagnie qui vend le produit WinDev, en l'occurrence PCSoft, et donc
«La Cie de développement» n'intervient en rien dans ce processus.
Q2. Est-ce que La base de données supporte le "Clustering" ? C'est-à-dire
2 serveurs
qui roulent en même temps et qui se partagent la charge de travail.
R2. Honnêtement nous n'en savons rien, puisque nous n'avons jamais eus de
plate-forme de test fonctionnelle avec ce type de configuration.
Par contre ce que l'on peut vous dire, c'est qu'il existe très peu
d'applications de type commerciale (et donc non spécialisé, comme des
logiciels de calcul scientifique ou des logiciels de Conception Assistée
par
Ordinateur) qui soit capable de gérer le "clustering".
Notre vision des choses tenterai a vous dire que la notion de "clustering"
reste dans la pluspart des cas du domaine du système d'exploitation.
Il existe des version du système d'exploitation Windows Server
spécifiquement écrite (et donc commercialisée) pour faire du "clustering".
Donc en théorie, si votre système d'exploitation gère le "clustering", alors
une application qui tournera sur ce serveur devrait en bénéficier à priori!
Q.3 Vous nous avez déjà confirmé, par courriel, que La base de données ne
supporte pas les serveurs avec double processeur, est-ce que c'est toujours
le cas ?
R3. Pour ce qui est des serveur Bi-Processeur, c'était probablement le cas
avec votre version de La base de données qui à été développé en WinDev 5.5
sur HF 5.5. Par contre cela sera sans doute faux pour votre future version
6 sur HF 7,
car la plate-forme de développement utilisé est désormais WinDev 7.5 ce qui
devrait permettre de supporter la gestion du multiprocesseur par le système
d'exploitation.
Comme précédemment expliqué pour le "clustering", la gestion du
multiprocesseur est généralement laissé à la charge du système
d'exploitation.
Les applications commerciales "optimisée pour le bi-processeurs" ne sont
certainement pas choses courantes, et il y à très peu de compagnie qui
peuvent se permettre d'investir dans ce genre de développement, car c'est
extrêmement onéreux !
Pour terminer, je vous confirme intuitivement également qu'il existe
d'autres facteurs de ralentissements d'une application : la première étant
généralement la quantité de données que l'on traite qui augmente au fur et
à
mesure qu'on l'utilise ! Faire un décompte d'inventaire avec 1500 produits,
sera forcément plus rapide qu'avec 150 000!
Cela semble une évidence, mais c'est aussi une réalité. |
| |
| |
| | | |
|
| | |
| |
Posté le 18 juin 2004 - 15:15 |
Bonjour,
voici l'avis que je peux vous doner après avoir travailler avec toutes les
versiosnde windev depuis la 1.5:
R1.A: Si vous parlez de l'utilisation à 50 % sur une machine monoprocesseur,
c'est vraisemblablement du à l'emploi de l'instruction multitache dans le
code de parcours du fichier. Cette instrcution est destinée à permettre au
système de reprendre la main pour effectuer d'autre taches (affichage d'information
quand à l'avancement du parcours par exemple), ou même spécifiquement (et
volontairement) pour ne pas trop charger le système et permettre à l'utilisateur
d'utiliser un autre programme pendant qu'une tache 'lourde' est effectuée.
R1.B: Si maintenant vous parlez de 50% d'utilisation sur une machine biprocesseur
(j'évoque cette hypothèse étant donné que vous abordez ce sujet ensuite),
ce la signifie simplement que 100% d'UN des processeurs est utilisé, ce qui
est le maximum qu'un programme non écrit spéciquement pour des machines multi-processeurs
peut faire.
R2. La base de données hyperfile ne supporte pas le clustering en soi. par
contre, si vous placez vos fichiers sur un ordinateur dont le système d'exploitation
supporte le clustering, rien n'empeche à priori hyperfile de fonctionner
dans ces conditions. De la même façon, la base de données HF ne fonctionne
pas sous linux, mais vous pouvez en placer une sur un serverur linux utilisant
samba pour être compatible avec windows au niveau de l'accès au fichier.
Et les performances en charge seront meilleures. Le clustering est effectivement
une fonction du système d'exploitation, pas des bases de données.
R3. Il est vrai que les programmes qui supportent le multiprocesseurs sont
généralement des programmes nécessitant de très fortes capacités de calcul.
Je n'en ai personnelemtn jamais vu dans le domaine de la gestion ou le goulot
d'étranglement est en genéral l'accès aux données. Il n'est d'ailleurs pas
sur du tout qu'utiliser un bi-processeur accélère vos traitement, si votre
accès disque est déjà saturé. Quand à Windev 8 et hyperfile 7, ils ne supportent
à ma connaissance pas plus le multiprocesseur que
Windev 5.5 et hyperfile 5. A part bien sur si vous voulez parler d'un développement
utlisant de multiples threads, ce qui n'est pas relié à la présence ou pas
d'un second processeur, et qui de plus n'est pas forcément une solution à
votre problème qui a l'air la vitesse d'accès aux données.
Maintenant, voici quelques considérations générales sur les causes habituelles
de lenteur d'accès aux données :
- Souvent, la 'lenteur' constatée est très relative, et plus psychologique
que réelle. Il m'est bien sur impossible de dire si c'est le cas ici, n'ayant
aucune information sur les volumes de données accédées, le nombre de fichiers,
les clés, et les traitements effectuées sur les données.
- Les premières choses à vérifier si vous constatez des lenteurs que vous
considérez anormales sont les suivantes:
1. Est ce que le phénomène se produit sur toutes les machines du réseau,
ou est ce que certaines machines sont plus rapides. Si le phénomène est
hétérogène, vous pouvez parier sur un problème matériel ou système.
2. Est ce que le programme est nettement plus rapide quand il est executé
directement sur le serveur (ie est ce le réseau qui ralentit le transfer
des données)... Si c'est le cas, voir du coté du réseau (il existe des articles
sur le web sur les problèmes de lenteurs que peut poser un réseau)
3. Est-ce qu'un économiseur d'écran est paramétré sur le serveur ou le poste
client en cause. Si c'est le cas, désactivez le et remesurez la vitesse.
Un économiseur d'écran sur votre serveur de fichier peut faire chuter les
performances de façon TRES importante.
4. Est ce que votre serveur de fichier est suffisament puissant par rapport
au nombre d'utilisateurs connectés. La quantité de RAM est à ce niveau extrèmement
importante. Si elle n'est pas suffisante, le serveur passe son temps à swapper
sur disque et les performances fichiers s'effondrent. Vous pouvez tester
si c'est le cas en faisant le meme traitement avec deux utilisateurs connectés
à la base au lieu de tout votre groupe (ne faite pas les essais avec un seul,
vous vous retrouveriez dans le cas optimisé de l'accès monoposte, ce qui
ne serait pas significatif)
5. L'architecture matérielle est très importante pour résoudre ce genre de
problèmes. La première démarches est d'identifier le goulot d'étranglement:
- Est ce que votre disque dur est utilisé à 100% durant ces traitements ?
- Est ce que le réseau est à 100 % ?
- Est ce que le processeur est à 100% (nous savons déjà que ce n'st pas le
cas)...
Une fois que vous avez trouvé le goulot d'étranglement, vous pouvez améliorer
les choses en changeant de système disque dans le permier cas (un groupe
de disques SCSI RAID peut nettement améliorer les choses), en réglant les
problèmes du réseau ou an augmentant sa vitesse dans le deuxième. Si leprocesseur
est à 100%, la seule solution (à part changer de processeur) est d'essayer
d'optimiser le code.
6. Avez vous explicitement demandé à vos développeur d'optimiser l'accès
à la base pour le traitement qui pose problème (si c'est UN traitement qui
pose problème, et pas tous les traitements). Il est parfois possible de modifier
la structure des fichiers pour que certains traitements soient plus rapide.
Cela se traduit en génral par un ralentissement lors d'autres traitements,
mais c'est parfois une solution pour résoudre un problème ponctuel.
7. Sachez que s'il est possible dans certains cas de rendre un traitement
plus rapide en développant un code particulier, ce genre d'optimisation prend
en général nettement plus de temps que le développement 'normal' du même
traitement. Dans le cas d'un développement spécifique, celà signifie aussi
un prix de développement nettement plus élevé et un devis que les clients
vont rarement accepter. Sauf une demande spécifique d'un client, ce genre
de démarche est donc rarement entreprise par les développeurs.
Voila, j'espères que mes commentaires vous auront aidé. J'ai peur qu'ils
ne fassent que vous montrer un peu plus la complexité du problème en question.
Cordialement
Fabrice Harari
fabriceh@selltis.com
"MZBARADAI" <mzbaradai@hotmail.com> wrote:
Une compagnie nous a développé une base de données lente ! J'ai posé 3 questions
aux développeurs qui m'ont répondu. Moi-même, je ne suis pas informaticien,
j'aimerais bien avoir l'avis ou l'analyse des développeurs chevronnés concernant
la réponse des développeurs de notre application.
Voici les 3 questions et réponse et mercis d'avance.
Q1. Pourquoi le processeur ne travaille pas à 100% quand on demande une
liste
d'inventaires dans La base de données ? Une job qui prend 2h quand le processeur
roule
à 50% devrait prendre 1h si le processeur roulait à 100% de ses capacités
!
Est-ce que c'est le "design" de la base de données qui ne permet pas de
profiter
de la
capacité du processeur ?
R1. Le design de La base de données n'est en rien responsable du taux d'occupations
CPU de votre serveur.
Cette gestion est plutôt du domaine du système d'exploitation du serveur,
et
éventuellement de l'outils de développement utilisé pour La base de données.
Dans le cas de La base de données il s'agit de WinDev 5.5 qui était normalement
optimisé pour tourner sur des postes Windows 95, Windows 98 ou Windows NT
4.
La façon dont le CPU sera utilisé lors de l'utilisation d'une application
développé avec cette plate-forme reste l'entière responsabilité de la
compagnie qui vend le produit WinDev, en l'occurrence PCSoft, et donc
«La Cie de développement» n'intervient en rien dans ce processus.
Q2. Est-ce que La base de données supporte le "Clustering" ? C'est-à-dire
2 serveurs
qui roulent en même temps et qui se partagent la charge de travail.
R2. Honnêtement nous n'en savons rien, puisque nous n'avons jamais eus de
plate-forme de test fonctionnelle avec ce type de configuration.
Par contre ce que l'on peut vous dire, c'est qu'il existe très peu
d'applications de type commerciale (et donc non spécialisé, comme des
logiciels de calcul scientifique ou des logiciels de Conception Assistée
par
Ordinateur) qui soit capable de gérer le "clustering".
Notre vision des choses tenterai a vous dire que la notion de "clustering"
reste dans la pluspart des cas du domaine du système d'exploitation.
Il existe des version du système d'exploitation Windows Server
spécifiquement écrite (et donc commercialisée) pour faire du "clustering".
Donc en théorie, si votre système d'exploitation gère le "clustering", alors
une application qui tournera sur ce serveur devrait en bénéficier à priori!
Q.3 Vous nous avez déjà confirmé, par courriel, que La base de données ne
supporte pas les serveurs avec double processeur, est-ce que c'est toujours
le cas ?
R3. Pour ce qui est des serveur Bi-Processeur, c'était probablement le cas
avec votre version de La base de données qui à été développé en WinDev 5.5
sur HF 5.5. Par contre cela sera sans doute faux pour votre future version
6 sur HF 7,
car la plate-forme de développement utilisé est désormais WinDev 7.5 ce
qui
devrait permettre de supporter la gestion du multiprocesseur par le système
d'exploitation.
Comme précédemment expliqué pour le "clustering", la gestion du
multiprocesseur est généralement laissé à la charge du système
d'exploitation.
Les applications commerciales "optimisée pour le bi-processeurs" ne sont
certainement pas choses courantes, et il y à très peu de compagnie qui
peuvent se permettre d'investir dans ce genre de développement, car c'est
extrêmement onéreux !
Pour terminer, je vous confirme intuitivement également qu'il existe
d'autres facteurs de ralentissements d'une application : la première étant
généralement la quantité de données que l'on traite qui augmente au fur
et
à
mesure qu'on l'utilise ! Faire un décompte d'inventaire avec 1500 produits,
sera forcément plus rapide qu'avec 150 000!
Cela semble une évidence, mais c'est aussi une réalité.
|
| |
| |
| | | |
|
| | |
| |
Posté le 18 juin 2004 - 16:45 |
Bonjour,
ne connaissant pas l'appli, je ne répondrai que sur le fond.
Windev génère des outils rapide pour peu que les problèmes soient bien traités.
A titre d'exemple, j'ai développé une base de données comportant actuellement
650 000 enregistrements et les temps de réactions sont de quelques secondes...
sincères salutations
"MZBARADAI" <mzbaradai@hotmail.com> wrote:
Une compagnie nous a développé une base de données lente ! J'ai posé 3 questions
aux développeurs qui m'ont répondu. Moi-même, je ne suis pas informaticien,
j'aimerais bien avoir l'avis ou l'analyse des développeurs chevronnés concernant
la réponse des développeurs de notre application.
Voici les 3 questions et réponse et mercis d'avance.
Q1. Pourquoi le processeur ne travaille pas à 100% quand on demande une
liste
d'inventaires dans La base de données ? Une job qui prend 2h quand le processeur
roule
à 50% devrait prendre 1h si le processeur roulait à 100% de ses capacités
!
Est-ce que c'est le "design" de la base de données qui ne permet pas de
profiter
de la
capacité du processeur ?
R1. Le design de La base de données n'est en rien responsable du taux d'occupations
CPU de votre serveur.
Cette gestion est plutôt du domaine du système d'exploitation du serveur,
et
éventuellement de l'outils de développement utilisé pour La base de données.
Dans le cas de La base de données il s'agit de WinDev 5.5 qui était normalement
optimisé pour tourner sur des postes Windows 95, Windows 98 ou Windows NT
4.
La façon dont le CPU sera utilisé lors de l'utilisation d'une application
développé avec cette plate-forme reste l'entière responsabilité de la
compagnie qui vend le produit WinDev, en l'occurrence PCSoft, et donc
«La Cie de développement» n'intervient en rien dans ce processus.
Q2. Est-ce que La base de données supporte le "Clustering" ? C'est-à-dire
2 serveurs
qui roulent en même temps et qui se partagent la charge de travail.
R2. Honnêtement nous n'en savons rien, puisque nous n'avons jamais eus de
plate-forme de test fonctionnelle avec ce type de configuration.
Par contre ce que l'on peut vous dire, c'est qu'il existe très peu
d'applications de type commerciale (et donc non spécialisé, comme des
logiciels de calcul scientifique ou des logiciels de Conception Assistée
par
Ordinateur) qui soit capable de gérer le "clustering".
Notre vision des choses tenterai a vous dire que la notion de "clustering"
reste dans la pluspart des cas du domaine du système d'exploitation.
Il existe des version du système d'exploitation Windows Server
spécifiquement écrite (et donc commercialisée) pour faire du "clustering".
Donc en théorie, si votre système d'exploitation gère le "clustering", alors
une application qui tournera sur ce serveur devrait en bénéficier à priori!
Q.3 Vous nous avez déjà confirmé, par courriel, que La base de données ne
supporte pas les serveurs avec double processeur, est-ce que c'est toujours
le cas ?
R3. Pour ce qui est des serveur Bi-Processeur, c'était probablement le cas
avec votre version de La base de données qui à été développé en WinDev 5.5
sur HF 5.5. Par contre cela sera sans doute faux pour votre future version
6 sur HF 7,
car la plate-forme de développement utilisé est désormais WinDev 7.5 ce
qui
devrait permettre de supporter la gestion du multiprocesseur par le système
d'exploitation.
Comme précédemment expliqué pour le "clustering", la gestion du
multiprocesseur est généralement laissé à la charge du système
d'exploitation.
Les applications commerciales "optimisée pour le bi-processeurs" ne sont
certainement pas choses courantes, et il y à très peu de compagnie qui
peuvent se permettre d'investir dans ce genre de développement, car c'est
extrêmement onéreux !
Pour terminer, je vous confirme intuitivement également qu'il existe
d'autres facteurs de ralentissements d'une application : la première étant
généralement la quantité de données que l'on traite qui augmente au fur
et
à
mesure qu'on l'utilise ! Faire un décompte d'inventaire avec 1500 produits,
sera forcément plus rapide qu'avec 150 000!
Cela semble une évidence, mais c'est aussi une réalité.
|
| |
| |
| | | |
|
| | |
| |
Posté le 21 juin 2004 - 04:43 |
Bonjour, pour resumer un peu l'excellente reponse de fabrice, un cas concret
auquel j'ai ete confronte :
une application de gestion, non developpee en windev et hyperfile mais en
visual foxpro, apres trois ans d'exploitation une lenteur incroyable plusieurs
minutes pour enregistrer une facture.
La configuration etait la suivante un serveur avec la base de donnees, l'application
installee sur les postes clients et un reseau pas tres rapide et pas beaucoup
de reponses de la part de la societe qui gerait notre installation.
Sur le serveur il y avait un disque en scsi a 7200, 128 mo de ram.
Nous avons change de serveur pour un serveur un peu plus puissant, 1go de
ram et deux disques sata en 10000 en raid 1
et installe le service terminal server, le probleme de lenteur a ete completement
resolu malgre la taille toujours grandissante de certaines tables.
Les donnees ne sont lues que sur un seul disque rapide et ne transite sur
le reseau que les informations d'affichage de la session tse.
Cette solution nous a permit de ne plus rencontrer de problemes de blocages
sur les fichiers qui equivalait a une sortie pas tres esthetique de l'application.
Cela devrai etre possible pour une application utilisant une base hyperfile. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|