|
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. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|