PyConFr 2014

La présentation sera organisée comme suivant

Introduction

Brève description du projet, simple démonstration.

Description de l'architecture asynchrone

L'architecture initiale de l'application a jusqu'à récemment été basée sur un processus "backend" utilisant asyncio + SQLAlchemy, avec des "workers" "front end" basés sur flask. Les processus "backend" et "frontend" communiquent au travers de 0mq + un protocole spécifique RPC.

Cette architecture était justifiée sur la base des problèmes spécifiques à l'application (génération de gros payload json, contraintes de vérification de gros fichiers en background, nombre/taille de fichier atteignant plusieurs dizaines de Go, etc...), et pour forcer une stricte séparation entre les parties sans état ("stateless") et avec état ("stateful").

Nous détaillerons aussi comment nous avons pu utiliser nginx pour non seulement servir de gros fichiers, mais aussi de manière moins classique accepter, et calculer les checksums à la volée de manière à ce qu'aucun processus python n'ait besoin de lire le fichier en mémoire.

Architecture courante

Des tests ont montre que l'architecture initiale n'était pas aussi robuste qu'espéré. En particulier, le processus "backend" causait des erreurs de type "segfault" régulières qui se sont révélées difficiles à réparer.

L'architecture a été simplifiée pour utiliser celery pour gérer les "jobs" en tâche de fond, et n'utiliser que des processus flask derrière nginx+gunicorn. L'architecture générale séparant les parties stateful/stateless a été conservée, mais sans une separation stricte entre processus.

Conclusion

Nous conclurons la presentation avec quelques chiffres de performance.