Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serveur(s) #8

Open
Changaco opened this issue Feb 20, 2017 · 5 comments
Open

Serveur(s) #8

Changaco opened this issue Feb 20, 2017 · 5 comments

Comments

@Changaco
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

Seb35 commented Feb 27, 2017

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
Copy link
Member Author

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
Copy link
Member

fgallaire commented Feb 28, 2017

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
Copy link
Member Author

Changaco commented Mar 1, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants