Legilibre / salon

Un salon pour les discussions générales autour du projet Légilibre
https://github.com/Legilibre/salon/issues
2 stars 0 forks source link

Serveur(s) #8

Open Changaco opened 7 years ago

Changaco commented 7 years ago

Le sujet d'une infrastructure commune pour les différents projets Légilibre a été évoqué plusieurs fois mais rien n'a vraiment émergé. Je pense qu'un inventaire des besoins et des propositions serait bénéfique.

Changaco commented 7 years ago

En ce qui concerne legi.py un serveur n'est pas strictement nécessaire mais pourrait être utile. Dans l'idéal il faudrait une machine avec "beaucoup" de RAM (pour que la BDD, qui pèse actuellement un peu moins de 4Go, tienne entièrement dedans) et un processeur suffisamment performant (pour les requêtes avancées et les mises à jours). Un disque dur SSD pourrait aussi accélérer les mises à jours.

Seb35 commented 7 years ago

Dans l’idée, ça m’intéressera aussi pour Archéo Lex à terme, mais je me rends compte que Archéo Lex nécessite vraiment des changements structurels assez importants pour atteindre un objectif de production journalier. Comme évoqué sur #2, il serait souhaitable d’utiliser legi.py pour l’import de LEGI et que Archéo Lex se concentre sur l’export, mais même pour cette seule étape il faut revoir l’architecture.

Pour le serveur, intéressé à terme pour AL, mais pour l’instant faire tourner AL sur une base régulière serait assez inefficace. Au niveau ressources, AL consomme surtout des input-output lors de la phase de création de la base de données (comme legi.py j’imagine) et surtout du processeur lors de l’export (pas de RAM lors de l’export, j’imagine que SQLite ne l’utilise pas avec sa config par défaut).

Changaco commented 7 years ago

La création de la BDD est contrainte à la fois par le CPU (décompression, traitement du XML, etc) et par le disque (écritures dans le fichier SQLite). L'export vers Git est limité par le CPU à cause des hashes, mais la vitesse de lecture des données depuis le fichier SQLite dépend bien de la RAM (SQLite n'a pas besoin d'utiliser explicitement la RAM comme un cache, le noyau s'occupe de ça).

fgallaire commented 7 years ago

Je ne pense pas que ce soit nécessaire de loader la BDD en RAM, il n'y a que quelques articles du code civil/pénal/travail qui intéressent les gens, et ils seront mis en cache rapidement.

Changaco commented 7 years ago

@fgallaire On ne parle clairement pas de la même chose. Toute opération complexe sur la BDD est beaucoup plus lente si la mise en cache en RAM n'est pas possible (je n'ai pas testé sur un SSD, mais même ce genre de "disque" est significativement plus lent que la RAM). Les opérations complexes incluent notamment : la mise à jour, la détection des anomalies, la génération de statistiques, et l'export des données.