Maj connection fichiers WLK vers mySQL

[NoSimbio]

Bonjour Jean,
Suite à notre échange sur le forum graphweather, ce qui m’intéresse beaucoup c'est d'être sur de pouvoir procéder à une mise à jour automatique de MySQL à partir des fichiers WLK avant de m'investir dans la construction d'un site avec HighCharts et HighStocks.
Avec mes remerciements,

Michel

[jturlier]

Re bonjour Michel,
vp2sql doit tourner en permanence, c'est lui qui effectue en temps réel les mises à jour de la base de données. Je t'enverrai par mail un lien pour que tu aies accès aux autres programmes, et en particulier ceux concernant les NOAA.
Les scripts réalisés pour la constitution du site à partir du modèle (highchart-highstock) de Pierre-André, récupèrent l'ensemble des données qui leurs sont nécessaires dans les différentes tables.

[NoSimbio]

Merci Jean,

Voilà, j'ai du grain à moudre, comme on dit!
Je pense que j'aurai beaucoup de questions; j'essayerai de les regrouper afin de ne pas trop déranger.
La première :
à terme, lorsque les graphs du site seront tous en highcharts, est-qu'il sera nécessaire de faire tourner graphweather ou seulement VP2SQL?
Je me dis que la question est peut-être idiote, mais graphweather ne sera plus sollicité pour créer les*.jpg?

Amitiés,

Michel

[jturlier]

Bonjour Michel,
En principe le modèle de Pierre-André n'utilise pas de données en provenance de GW, ici par exemple, il n'est plus utilisé, tout est réalisable sans lui.
Tu peux aussi noter, qu'aucun graphe jpeg n'est plus utilisé, les graphes interactifs les remplacent avantageusement !
Je te suggère de te créer un site "bis" dans le répertoire de base de ton site.
Tu as aussi la solution beaucoup plus souple,d'installer Wamp sur ta machine locale et tu auras ainsi ton propre serveur (html, mysql avec PHP) (adressable par "http://localhost". L'intérêt c'est que tu peux faire tout ce que tu souhaites sans affecter ton site distant... et tu apprends à comprendre et maitriser ainsi l'architecture de ton site.
Pour les questions, il vaut mieux les adresser au fur et à mesure, avec des titres significatifs, ou utiliser des sujets les traitant déjà.
Tu peux m'adresser directement ce qui est utilisation de base de MySQL si ce n'est pas déjà traité... pas trop souvent
Profite en bien pour apprendre les différents langages, PHP, Javascript,SQL... Tu as le confinement devant toi !!!
Bien amicalement

[NoSimbio]

Bonjour Jean,
Merci pour cette réponse circonstanciée.
J'ai été amené à installer wamp, serveur local, pour une autre raison. En me servant VP2SQL, je me suis aperçu qu’après avoir télécharger environ 2500 enregistrements relativement rapidement, environ 30mn, il fallait ensuite environ 5mn pour transférer chaque enregistrement suivant.
J'ai pensé que cela pouvait peut-être venir d'une limitation de volume d'accès distant aux BDD venant de l'hébergeur. J'ai donc installer wamp et créer une BDD locale. Après avoir reconfigurer VP2SQL le transfert a été rapidement fait, mais avec le même problème en fin de transfert, environ 5mn par ligne.
Je viens de recommencer l'expérience: même cause, même effet, mais le transfert bute sur d'autres enregistrements situés plus en aval.
J'ai jeté un coup d' oeuil sur le fichier wlk, avec "editwlk-long", les lignes qui posent problème ne semblent pas corrompues. Peut-être un problème de mémoire. Pour info j'utilise un mini-pc avec 8go processeur Celeron J3455 ssd 128go w10pro.
Comment puis-je éviter cela?

Autre question : quel est l'effet de l'utilisation de l'option "automatique" dans le menu chargement de VP2SQL et quel est le délai de maj de la base mySQL par ce logiciel?
Avec tous mes remerciements et mes excuses pour te déranger le week-end.

Michel

[jturlier]

Re-bonjour,
c'est normal que le chargement initial prenne beaucoup de temps.
En fonctionnement normal (hors chargement initial) le délai entre 2 vérifications du fichier wlk est de 5 minutes. S'il n'y a pas eu de nouvel enregistrement, il ne se passe rien. S'il y en a eu un ou plusieurs, le programme l'insère ou les insère alors dans la base de données.
Si le nombre d'enregistrements à insérer prend plus de 5 minutes, le temporisateur est sans effet.
Quand on fait le chargement initial, pour les gens qui connaissent SQL, on peut supprimer les index et clés primaires, ce qui accélère notablement le traitement initial. On doit ensuite, une fois ce traitement terminé, les recréer et relancer le chargement. Quand on charge plusieurs années, il faut parfois plusieurs jours de chargement.
Si tu travailles avec ta base locale, c'est plus rapide. Il suffit ensuite de lancer copie4sql (en ayant pris soin de détruire la table data sur le site distant), à ce moment, on utilise un des utilitaires de MySQL qui effectue un dump sur la base locale sans les index, et le copie sur la base distante. Une fois la copie terminée, copie4sql recrée les index et tout fonctionne à ce moment là ligne par ligne. Si on arrête l'opération en cours, on repasse en mode ligne par ligne.
Les programmes travaillent en séquence sur les timestamp et ne peuvent pas traiter une rupture de séquence. Les enregistrements non séquentiels sont ignorés.
La case à cocher automatique permet de passer dans le bon ordre d'un fichier wlk au suivant. (je ne me souviens pas si elle sert toujours à quelque chose!)

J'espère que tu as compris quelque chose à mon charabia, il y a déjà eu quelques questions sur le sujet dans le passé, peut-être trouveras-tu d'autres informations !

[NoSimbio]

Merci Jean pour tes explications.
J'ai cherché en vain sur le forum un sujet similaire.
J'ai bien compris que l'exportation vers une BDD distante peut être très longue, et merci pour les explications sur les délai d'envoi de VP2SQL.
Là je travaille sur une BDD locale.
pour repartir à zéro :
- je supprime la table data,
- j'importe avec VP2SQL le fichier 2020-11.wlk ( un seul, je n'ai qu'environ 15 jours sur novembre)
- l'import se fait bien (moins de deux mn) et ralentis fortement alors qu'il y a encore plusieurs heures à importer.
Voici un extrait du log de VP2SQL :
------------------------------------------------
enreg 202011281310 18:53:59.0085683
enreg 202011281315 18:53:59.0464047
enreg 202011281320 18:53:59.1089598
enreg 202011281325 18:53:59.1623751
jusque là environ 2500 enreg. ont été importés rapidement

2020-11.wlk 202011281325 18:53:59.1623751
2020-11.wlk 202011281325 18:54:29.1708424
enreg 202011281330 18:54:29.5602241

2020-11.wlk 202011281325 18:54:29.5758574
2020-11.wlk 202011281330 18:54:59.5947806
2020-11.wlk 202011281330 18:54:59.9485216
2020-11.wlk 202011281330 18:55:29.9784437
2020-11.wlk 202011281330 18:55:30.3787285
2020-11.wlk 202011281330 18:56:00.3894743
2020-11.wlk 202011281330 18:56:00.7435102
2020-11.wlk 202011281330 18:56:30.7406541
enreg 202011281335 18:56:31.1076201

2020-11.wlk 202011281330 18:56:31.1232709
2020-11.wlk 202011281335 18:57:01.1302845
2020-11.wlk 202011281335 18:57:01.4776691
2020-11.wlk 202011281335 18:57:31.4803519
2020-11.wlk 202011281335 18:57:31.7997763
2020-11.wlk 202011281335 18:58:01.8043193
2020-11.wlk 202011281335 18:58:02.1539970
2020-11.wlk 202011281335 18:58:32.1710448
2020-11.wlk 202011281335 18:58:32.6029801
2020-11.wlk 202011281335 18:59:02.5972875
2020-11.wlk 202011281335 18:59:02.9671289
etc----------------------
le délai pour importer chaque enreg devient de plus en plus long
Pour l'instant je n'ai pas trouvé de solution, mais je suis loin d'être un expert!
Merci

Michel

[jturlier]

Re,
c'est une grosse erreur d'avoir un pas d'enregistrement d'une minute ! Généralement on utilise un pas de 5 minutes ce qui est bien suffisant, on ne rate rien, pour le vent par exemple, on récupère la rafale maxi pendant la période de 5 minutes avec l’échantillonnage de 2.5s de WLK .
C'est donc normal que tu aies une augmentation significative du temps de traitement comme si tu avais 5 mois de données.Cela semble malgré tout bien lent ! Ton minipc ne semble pas être un foudre de guerre, jette un coup d'oeil sur le gestionnaire de tâches, et regarde le pourcentage d'occupation du processeur qui doit être plutôt élevé avec wlk (qui est très gourmand) et mysql. VP2sql n'est pas gourmand en ressources, seulement quelques pourcents.
En résumé, je te suggère avec ce type de machine,
1 de ramener ton pas à 5 minutes,
2 de passer à cumulus 1.4.9 (pas MX)
Pour le point 2, tu installes cumulus, tu arrêtes wlk, lances cumulus. Une fois que la partie wlk a fini de se charger, tu installes cumulus2sql et tu continues le chargement de ta table, pas de pertes de données et ta base continue de se remplir !

[NoSimbio]

Bonjour Jean et bon dimanche,
Je dois te présenter mes plus plates excuses pour t'avoir fait perdre ton temps!!
Je viens de me rendre compte que le problème de transfert venait de certaines vcredist.x86 ou 64 manquantes pour faire tourner correctement wamp64.
Je reste donc sur VP2SQL et weatherlink qui fonctionne bien sur le mini-pc(il n'y a que le nécessaire pour la station VP2 dessus).
Je suis confus, et encore merci pour ton investissement à résoudre mes propres soucis.

Michel

[jturlier]

Salut Michel,
de la discussion nait la lumière.
L'important, c'est que tu t'en sois sorti.
Amicalement
Jean