-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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. |
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). |
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). |
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. |
@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. |
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.
The text was updated successfully, but these errors were encountered: