|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Latences HFSQL C/S : Accès concurrents. |
| Débuté par MicLD, 22 mai 2018 10:23 - 7 réponses |
| |
| | | |
|
| |
Membre enregistré
28 messages
Popularité : +3 (3 votes) |
|
Posté le 22 mai 2018 - 10:23 |
Bonjour
Lors de nos nombreux tests de montée en charge multi-utilisateurs, nous avons mis en évidence un phénomène de latence récurrent.
Latence très marquée, liée au nombre d’accès simultané base de données HFSQL Client / Serveur.
Concrètement :
Plus le nombre d’utilisateurs augmente, plus les temps de réponse du moteur de base de données se dégradent.
Test de montée en charge en mode « stressing » ou en mode « prod ».
Les tests ont été réalisés à partir de l'application CRM (fournie par PC SOFT).
Dans ce projet, nous avons basculé la BDD en Client / serveur.
Nous avons également rajouté un bouton <TEST 1> pour faire nos mesures :
hDebut,hFin sont des Heures
sLstFichier est une chaîne
duTmp est une Durée
sLstFichier = HListeFichier()
TANTQUE Vrai = Vrai
Multitâche(100)
hDebut = Maintenant
POUR TOUTE chaîne sFic de sLstFichier SEPAREE PAR RC
HLitPremier(sFic)
TANTQUE PAS HEnDehors(sFic)
HLitSuivant(sFic)
FIN
FIN
hFin = Maintenant
duTmp = hFin - hDebut
Trace(DuréeVersChaîne(duTmp, "SS sec LLL"))
FIN
Plateformes de test :
Serveur Windows 2012 R2 (64 bits)
Processeur : Intel® Xeon® CPU E 5606 @ 2.13 GHz (4 cœurs physiques)
RAM : 32 Go
Disque dur : 2 Disques 15 K Trs/min en RAID de 300 Go
(Le serveur est largement surdimensionné et aucun matériel ne sature lors des tests.)
Sur ce serveur, nous avons installé l’application CRM, ainsi que HFSQL Client/Serveur (230050g)
Gestion des Cache : 3603 Mo
Cache disque : Automatique
Protocole de reproduction de nos tests :
1) Lancer 1 fois l’application CRM
2) Cliquer sur le bouton <TEST 1>
Observer les temps de réponse
=> Relativement stable (aux environs de 1 s 09)
3) Lancer simultanément d’autres instances de l’application CRM , en cliquant à chaque fois sur le bouton <TEST 1>.
Observer les temps de réponse
=> le temps de réponse augmentent rapidement et sont de moins en moins stable (aux environs de 3 s 50 pour 7 utilisateurs).
Conclusion :
Très rapidement, lorsque plusieurs requêtes sont envoyées simultanément au moteur de base de données, les temps de réponses explosent.
Le moteur de base semble ne pas être en mesure de gérer plusieurs utilisateurs.
Pourquoi ? des réglages sont-ils à effectuer, mais où ?
D'avance merci à tous ceux qui se seront penchés sur notre post ! |
| |
| |
| | | |
|
| | |
| |
Posté le 22 mai 2018 - 14:27 |
Bonjour,
Tu m'étonnes…. avec une boucle de lecture avec les ordres Hxxx c'est plus ton réseau qui sature que ton server : 1 ordre Hxxx = 1 requête
Ce qui plombe les performances ce n'est pas le volume de données échangé mais le nombre de requête c'est la genèse
Ce test n'est pas significatif tu va avoir le même phénomène avec un autre serveur de DB
Bon Dev
Marc Fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
28 messages
Popularité : +3 (3 votes) |
|
Posté le 22 mai 2018 - 15:13 |
Bonjour,
Les tests mis en placent ne correspondent effectivement pas à une utilisation standard d'une application par 7 utilisateurs.
Mais ce mode de test peux nous permettre de simuler un montée en charge plus importantes (entre 50 et 100 utilisateurs).
Autrement dit, nous avons estimé que 7 utilisateurs en mode "stressing" ( = interrogation intensive de la BDD) pouvait correspondre à X utilisateurs en environnement de production.
Est-ce incohérent ?
Nous avons tout de même été surpris qu'un moteur de base de données "robuste et performant" multiplie par 3 les temps de réponses lorsqu'il y a 7 accès concurrent.
Comment se comportent ces outils avec 100, 500 voir 1000 utilisateurs ? |
| |
| |
| | | |
|
| | |
| |
Posté le 22 mai 2018 - 15:50 |
MicLD a écrit :
Bonjour,
Les tests mis en placent ne correspondent effectivement pas à une utilisation standard d'une application par 7 utilisateurs.
Mais ce mode de test peux nous permettre de simuler un montée en charge plus importantes (entre 50 et 100 utilisateurs).
Autrement dit, nous avons estimé que 7 utilisateurs en mode "stressing" ( = interrogation intensive de la BDD) pouvait correspondre à X utilisateurs en environnement de production.
Est-ce incohérent ?
Nous avons tout de même été surpris qu'un moteur de base de données "robuste et performant" multiplie par 3 les temps de réponses lorsqu'il y a 7 accès concurrent.
Comment se comportent ces outils avec 100, 500 voir 1000 utilisateurs ?
Tu stresses tout autant ton réseau que ton serveur, ce serait intéressant de le faire avec un autre serveur SQL il est possible que ce ne soit pas plus convainquant
1000 users perso j'utilise SQL server, par user le cout de la licence est dérisoire, HFSQL ( gratuit ) je vais jusque 100 user ( bcp d'expérience avec +- 50 et pas de soucis, bien entendu je n'utilise pas les orders hxxx uniquement des requêtes SQL avec Hlitpremier / hsansrafraichir )
Bon Dev
Marc Fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
1 623 messages
Popularité : +100 (114 votes) |
|
Posté le 22 mai 2018 - 16:02 |
Si tu fonces dans un mur avec ta voiture a 200 km/h, l'airbag va se déclencher surement.. mais son efficacité sera peut être moindre qu'a 110.
Faire des HlitSuivant en boucle tout les X millisecondes c'est un peu la même chose.
Ça va fonctionner mais moins bien.
Avoir tous tes users qui font des "SELECT *" sans arrêt (puisque c'est ce que font les fonctions Hxx) ce n'est plus un problème de moteur de données mais d'optimisation du client.
Vu la configuration du test, ce ne sont pas 7 clients mais des centaines en réalité vu la fréquence des requêtes qui font une grande quantités de requêtes non optimisées, effectivement ça va faire ralentir le serveur, mais bon, ce résultat est tout à fait normal. D'ailleurs si tu l'execute depuis le debugguer avec un GO depuis l'ide windev, tu devrait avoir une alerte (point d'exclamation dans le code) qui va t'avertir que tu as répété XX fois la même requête au cours des dernières 60 sec et va te proposer d'optimiser tout ca.. |
| |
| |
| | | |
|
| | |
| |
Posté le 22 mai 2018 - 16:04 |
Le 22/05/2018 à 13:13, MicLD a écrit :
Bonjour,
Les tests mis en placent ne correspondent effectivement pas à une
utilisation standard d'une application par 7 utilisateurs.
Mais ce mode de test peux nous permettre de simuler un montée en charge
plus importantes (entre 50 et 100 utilisateurs).
Autrement dit, nous avons estimé que 7 utilisateurs en mode "stressing"
( = interrogation intensive de la BDD) pouvait correspondre à X
utilisateurs en environnement de production.
Est-ce incohérent ?
Non car les utilisateurs ne vont pas parcourir un fichier du début à la
fin et encore moins tous en même temps...
Selon ton application les utilisateurs vont afficher un liste (pour toi
une requete, un parcours hlit..., un pour tout etc.) puis ouvrir une
fiche plus faire une pause d'une durée variable et recommencer.
Pour une appli de gestion...
C'est fonction de chaque appli...
eric l.
Nous avons tout de même été surpris qu'un moteur de base de données
"robuste et performant" multiplie par 3 les temps de réponses lorsqu'il
y a 7 accès concurrent.
Comment se comportent ces outils avec 100, 500 voir 1000
utilisateurs ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
28 messages
Popularité : +3 (3 votes) |
|
Posté le 22 mai 2018 - 16:34 |
Vos réponses vont dans le même sens : Mes tests ne sont pas cohérents.
=>OK, Comment procéderiez-vous pour simuler 50 utilisateurs ?
Nous avons réalisé ces tests car nous développons un ERP et nous commençons à avoir des sites avec +- 50 utilisateurs.
Sur nos machines de développement les temps de réponses sont très corrects. Mais nous avons des difficultés à obtenir les même temps de réponses sur nos sites. (Malgré la mise en place de serveur performant.)
Marc, si je comprend bien, tu utilises un maximum des sources de données globale que tu ne rafraîchis jamais ?
(exemple pour la lecture de paramètres etc...) Donc tu utilises plus la RAM que le processeur du serveur. |
| |
| |
| | | |
|
| | |
| |
Posté le 22 mai 2018 - 18:14 |
MicLD a écrit :
Vos réponses vont dans le même sens : Mes tests ne sont pas cohérents.
=>OK, Comment procéderiez-vous pour simuler 50 utilisateurs ?
Marc, si je comprend bien, tu utilises un maximum des sources de données globale que tu ne rafraîchis jamais ?
(exemple pour la lecture de paramètres etc...) Donc tu utilises plus la RAM que le processeur du serveur.
Dans le cadre de mon framework en effet certaines données de "paramètres" statiques sont chargées en mémoire ( devises, taux de change, conditionnement globaux, pays, codes TVA.... ) et rafraichie au besoin par un système d'évênements interne au logiciel, cela ne charge que tres peu la mémoire
mais pour le reste chargement de requêtes quand nécessaire et binding sur objets, une commande ou une fiche de prod de 500 lignes avec tout autant d'objet instanciès ( et même bcp plus ) charge bien plus la mémoire que ces paramètres, mais la mémoire par PC ce n'est plus vraiment critique ( et j'ai connu les 64K donc je sais de quoi je parle..) ,j'ai d'ailleurs des postes en W10 avec 2GB sans soucis , et mon ERP est full multifenêtrable donc parfois 10 documents logistiques ouverts
50 user c''est peanuts, j'arrive à tenir cette charge sur une DB HF/SQL hébergée sur le cloud, et sans fibre, la seule chose c'est qu'il faut faire tres attention à la taille des images si il y en a...
Bon Dev
Marc Fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|