Discussion :

[dus]

Bonjour,

Je viens de transférer une application développée sous Windev 23 d'un pc (i7 4770S 3.1ghz, 8Go de ram) à un serveur virtuel (Windows server 2022 - AMD EPYC 7502 32-Core Processor 2.50 GHz (4 processors)).
Cette application effectue un traitement quotidien qui dure entre 1h15 et 1h30 en fonction des données d'entrée.
En gros, analyse de fichiers xml émis par un ERP (entre 1000 et 10000 fichiers par jour) et mise à jour d'une base de données MySQL, localisée sur un serveur (pas celui sur lequel l'application a été transférée).

Pour tester la migration, j'ai lancé manuellement une des tâches de ce traitement qui est assez représentative du traitement global (1 minute 30 s sur le pc original) - verdict sur le serveur virtuel 37 minutes.
Cette tâche exécute des requêtes SQL dans une table de nomenclatures (220000 enregistrements), dans une procédure récursive, et en fonction des résultats écrit dans une autre table.

J'ai testé ce type de requêtes directement sous MySQL Workbench (installé sur le serveur virtuel) et je ne constate aucune lenteur significative.

J'ai demandé à mon service IT d'améliorer les performances du serveur virtuel. Je ne sais pas trop ce qui a été fait ( à priori passage de virtual CPU de 2 coeurs à 4), mais aucun effet.

Avez vous déjà eu ce genre d'écueil sous Windows server ?

[ben-34]

Bonjour,

Effectivement, le changement de plateforme peut donner de bonnes surprises.
Les fonctions 'AnalyseurDebut()' et 'AnalyseurFin()' sont terriblement efficaces pour diagnostiquer les points d'engorgements et comparer les performances de différents systèmes.

[frenchsting]

Bonjour,

J'ajouterai également, que passer de 2 à 4 cœurs ne sert pas à grand-chose si le traitement est surtout de la lecture de données.
- Pas contre, l'augmentation de la RAM,
- Et surtout (s'il existe un option dans ce sens), une priorisation de l'accès réseau,
sont des choses à envisager.

Question : Utilises tu le connecteur natif ?

[dus]

Petit oubli de ma part, le pc original tourne sous W10 pro.
Mes connaissances en Windev sont plutôt limitées. Je suis à la base informaticien industriel.
J'assure la maintenance de cet outil qui a été sous-traité et dont le créateur est devenu retraité.

Je ne connaissais pas ces fonctions d'analyse. Après, je n'ai pas l'impression qu'un algorithme qui passe en revue 220000 enregistrements en 1 minute 30 sur un i7 qui a presque 10 ans soit foncièrement mauvais.

[philouZ]

Est-ce que tu utilises l'accès natif ou un accès ODBC ?

[dus]

A priori la ram dédiée au serveur est identique au pc original, soit 8Go.
Concernant la connexion à la base MySQL, elle est faite par accès natif MySQL pour WINDEV.

[dus]

Je viens de tester un autre outil sur le serveur, qui lui, utilise la même base MySQL, mais plutôt en lecture, développé aussi sous Windev 23.
Je ne constate pas vraiment de lenteur par rapport à mon pc de dev.

[philouZ]

L'idéal est de lancer un audit de ton appli pour trouver la partie qui pose soucis.

Essaye de lancer un audit avec "Shift + Windows + F10"

[dus]

Windev n'est pas installé sur la cible qui pose souci.

[philouZ]

Windev n'est pas installé sur la cible qui pose souci.

Aucune importance, cette fonctionnalité est intégrée dans l'exécutable.

[dus]

Je viens de passer l'audit sur les 2 cibles.

Une liste de fichier sur un emplacement réseau est effectué une fois en début de tâche par fListeFichier

La méthode récursive est appelée environ 48500 fois.
A chaque appel :
- une requête SELECT lancée sur la base mySQL (hébergée sur un autre serveur) par HExécuteRequêteSQL sur une table de 220000 enregistrements,
- un appel à HLitPremier
- une requête SELECT sur une autre table par HExécuteRequêteSQL
- en fonction des résultats des 2 select un ajout effectué par HAjoute sur une autre table.

fListeFichier :
sur pc i7 : 2.794s
sur serveur virtuel : 35.720 s

HExécuteRequêteSQL (52665 appels)
sur pc i7 : 700µs en moyenne
sur serveur virtuel : 22ms en moyenne

HLitPremier (48488 appels)
sur pc i7 : 580µs en moyenne
sur serveur virtuel : 22ms en moyenne

HAjoute (3838 appels)
sur pc i7 : 220µs en moyenne
sur serveur virtuel : 300µs en moyenne

HLitSuivant (52622 appels)
sur pc i7 : 18µs en moyenne
sur serveur virtuel : 28µs en moyenne

[Yusep]

Bonjour
Il faudrait vérifier l'état du réseau physique (switch) de la machine virtuelle.
Avec LAN_SpeedTestPortable par exemple.

[philouZ]

Les temps ne me semblent pas déconnant, en sachant que tout dépend de la qualité de la connexion.

Ce qui m'intrigue le plus, c'est le nombre de fois où ta procédure est appelée. A mon avis c'est là que tu dois travailler, surtout qu'au final tu n'insères que 8% de tes résultats dans ta base. N'aurais tu pas intérêt à trouver une solution pour travailler tes données en mémoire plutôt que de faire des aller-retour vers le serveur ?

Pour lister les fichiers, peut-être qu'utiliser un serveur ftp serait plus rapide que de lister les fichiers sur le réseau ?

Quand tu exécutes ta requête, est ce que tu utilises "hRequêteSansCorrection". Dans le HLitPremier, as tu essayé les options "hSansRafraichir" ou "hForwardOnly" ?

[dus]

Les temps ne me semblent pas déconnant, en sachant que tout dépend de la qualité de la connexion.

Ce qui m'intrigue le plus, c'est le nombre de fois où ta procédure est appelée. A mon avis c'est là que tu dois travailler, surtout qu'au final tu n'insères que 8% de tes résultats dans ta base. N'aurais tu pas intérêt à trouver une solution pour travailler tes données en mémoire plutôt que de faire des aller-retour vers le serveur ?

Pour lister les fichiers, peut-être qu'utiliser un serveur ftp serait plus rapide que de lister les fichiers sur le réseau ?

Quand tu exécutes ta requête, est ce que tu utilises "hRequêteSansCorrection". Dans le HLitPremier, as tu essayé les options "hSansRafraichir" ou "hForwardOnly" ?

Oui il y a bien hRequêteSansCorrection et hSansRafraichir.
La procédure est effectivement beaucoup appelée. C'est une gestion de nomenclature, avec une relation père-fils entre les colonnes. On est obligé de parser tous les éléments de la nomenclature sans connaitre le nombre de branches dans l'arbre, ni la profondeur, jusqu'à déterminer tous les éléments ayant un attribut particulier.
Il y a effectivement sûrement matière à optimiser. La question ne s'était jamais posée tant que la durée de la tâche ne remettait pas en cause la façon de faire.

Concernant les fichiers listés, ce sont des documentations directement accessibles à tous les employés, pas moyen de modifier ça.

[philouZ]

On est obligé de parser tous les éléments de la nomenclature sans connaitre le nombre de branches dans l'arbre, ni la profondeur, jusqu'à déterminer tous les éléments ayant un attribut particulier.

Il n'y a pas moyen de faire une requête récursive qui remonte tous les éléments concernés ?

Il faut quand même vérifier que la config réseau ne pose pas de problème. Pas de soucis au niveau d'un pare-feu ou d'un antivirus ?

[dus]

Bonjour
Il faudrait vérifier l'état du réseau physique (switch) de la machine virtuelle.
Avec LAN_SpeedTestPortable par exemple.

débit en lecture 5 fois plus important côté pc, 4 fois en écriture

[dus]

Il n'y a pas moyen de faire une requête récursive qui remonte tous les éléments concernés ?

Il faut quand même vérifier que la config réseau ne pose pas de problème. Pas de soucis au niveau d'un pare-feu ou d'un antivirus ?

pare-feu sur la vm désactivé
concernant les requêtes récursives, je dois avouer que ça tutoie mes limites sur le sujet...

[frenchsting]

Bonjour,

Comme je le disais, une optimisation de l'accès réseau serait un plus.

Autre idée : Ton appli, va semble t'il, lire d'une manière ou d'une autre lire l'intégralité des 220 000 enregistrements. Ne serait il pas intéressant de lire tout en une fois et de faire tes recherches directement en mémoire ?

[dus]

Bien sûr qu'il doit y avoir à optimiser.
Les quelques jours qui me sont alloués étaient prévus pour une migration de cible.
Cette casquette d'informatique de gestion ne peut pas dépasser un pourcentage faible de mon planning.

Je vous remercie tous pour le temps passé.
J'espère pouvoir cocher "Résolu" si mon service IT parvient à m'accélérer tout ça.

[Yusep]

débit en lecture 5 fois plus important côté pc, 4 fois en écriture

Donc, c'est clair, il y a problême de réseau non de machine virtuelle.
J'ai fait des essais de requête sur une VM avec 50000000 de registres sans noter de lenteur.