Idée pour rendre alan.cienokill.fr plus stable
Closed this issue · 7 comments
Problème au niveau de l’expérience utilisateur :
- Chaque jour ou un mail groupé ou un post sur un réseau social partage le lien, le serveur crash une ou deux fois. Cela implique que des personnes sont coupés en pleine conversation et que d'autres cliquent sur un lien mort.
Source du problème :
- Alan ne peut pas être hébergé par un ovh ou autre hebergeur traditionnel car c'est un serveur python.
- Heberger Alan à la maison s'avère instable à cause de :
- Notre faible experience en réseau / serveur.
- Fiabilité du materiel (rpi)
Idée de solution :
Séparer alan en deux :
Heberger la façade (frontend : html/js/...) sur un serveur de confiance (e.g. OVH)
Heberger le cerveau (backend : python/rivescript/...) à la maison.
Ainsi la façade est toujours accessible et quand le cerveau est crashé (ou qu'il est provisoirement etteint à cause d'un demenagement ou d'une coupure de courant), afficher un message du genre Alan n'est pas disponnible pour le moment, revenez demain
Est ce qu'il n'y avait pas aussi l'idée d'effacer régulièrement database sqlite3 ?
oui en effet. Le problème c'est que ça reset le compteur de conversation.
Donc dans l'état actuel du programme on serait un peu obligé de supprimer/archiver toutes les conversations passées à chaque clean de la base de données (elles ne seront plus accessibles depuis le /dev panel)
La question qu'on doit se poser
est ce qu'on peut continuer à communiquer sur Alan ou est ce qu'il faut régler tout ça avant que les conversations affluent ?
Synthèse des solutions
D'aprés l'analyse de Léon je vois 4 améliorations possibles :
- changer le RPI pour un serveur plus sérieux
- héberger la facade chez OVH
- régler ce problème d'engorgement de la base de données sans perdre les fonctionnalités de dev pannel
- solliciter l'aide d'un administrateur réseau, le temps de stabiliser le bignou.
Dans tous les cas j'imagine que c'est pas mal de boulot que je ne sais pas faire. Donc......je peux juste émmettre des suggestions :
Une piste pour le problème de l'engorgement de la base de données
Je ne sais pas comment marche dev panel, alors ce que je vais dire est peut-être idiot...
mais sur mon ordi le reset de database sqlite3 n'a pas effacé les anciens fichiers log de mon dossier log. Est ce que dev ne pourrait pas pointer ce dossier plutôt que la base de données ? (J'ai l'impression que les nouveaux fichiers log éffacent les anciens du même nom ? peut-être changer de nom tous les jours ? ou après un reset ?)
mais sur mon ordi le reset de database sqlite3 n'a pas effacé les anciens fichiers log de mon dossier log. Est ce que dev ne pourrait pas pointer ce dossier plutôt que la base de données ? (J'ai l'impression que les nouveaux fichiers log éffacent les anciens du même nom ? peut-être changer de nom tous les jours ? ou après un reset ?)
Non ça n'effacera pas les fichiers logs mais vu que ça reprend le compte à zero, le fichier de la conversation 0001 par exemple, il va écraser (ou se mellanger avec) le fichier de l'ex-conversation 0001.
Si dans les todo il y a une note sur la conversation 0234 on aura pas de moyen de savoir de quelle conversation 0234 il s'agit.
Donc la solution c'est que quand on efface la bdd il garde le compte là ou il en était. Mais ça necessite de se repencher un peu sur le code qui concerne la bdd. Code qui est bien poussiéreux.
pour info, il y a des serveur LENONVO d'occas à 200 euros
Compte rendu de mes bidouillages du jour
Reduction des appels à la base de donnée
J'ai essayé d'enlever tous les appels à la base de donnée dont on pouvait se passer dans les differents adapters. Depuis quelques version, la conversation en cours est stockée dans la memoire vive. Donc inutile d'avoir recours a la base de donnée si c'est juste pour un renseignement sur la conversation en cours.
Il en reste quelques-uns mais bcp moins
Je pense qu'on a un peu gagné en efficacité.
Attention cependant même si j'ai essayé de faire des test de tout ce que je modifiais, il se peut qu'il y ait des bugs qui surgissent suite à ces modifs. Donc rester aux aguets.
Système d'archivage semi-auto.
Un petit script sur le server copie tous les logs et la base de donnée dans un dossier archives/ et remet les logs et la bdd à zéro.
Ce script n'est pas pour l'instant lancé automatiquement par le sever. Mais on pourrait réfléchir à l'executer par exemple tous les mois. (?)
En gros ça fait que sur le server le compte reprend à 0 et sur le dev panel on n'a plus accès aux conversations précédentes. Si on veut retrouver des vieilles conversations il faut venir les chercher à la main sur le server dans le dossier archives/
Même si j'ai supprimé pas mal d'appels à la base de donnée dans le code, il en reste. Et une telle remise à zero fait du bien a alan je pense.
Aussi j'ai un peu merdé et pendant que je gerait l'automatisation des archives j'ai fais une fausse manip, on a perdu quelques logs de conversation. Désolé....
Séparation Frontend/backend
Donc mtn c'est plus le meme server qui fournit les pages web et l'api du chatbot. Les pages web sont servies par ovh à l'adresse alan.cienokill.fr. Quand à l'api python elle tourne sur le raspberry et est accessible à l'adresse brain.alan.cienokill.fr
En gros, si je vais sur brain.alan.cienokill.fr j'ai pareil que ce qu'il y avait avant sur alan.cienokill.fr
Si je vais sur alan.cienokill.fr j'ai la même interface mais elle est accessible même si le rpi est debranchée. Bien sur si le rpi est debranché, je ne peux pas utiliser l'interface, mais au moins elle est là et elle affiche un petit message du genre "alan est absent revevez demain"
Nota bene Consequence de ça : alan.cienokill.fr/dev ne marche plus. Il faudra aller sur brain.alan.cienokill.fr/dev pour avoir le dev panel.
voilà voilà, si vous avez des questions n'hesitez pas.
en pratique tout ca est fonctionnel et on devrait avoir reglé le gros de nos soucis. Reste a voir si ça marche aussi en pratique.
Il semblerait qu'on ait déjà un administrateur réseau qui stabilise le biniou ^^