Architecture technique – vers PostgreSQL

Par Élie Sloïm, le 2 avril 2013, dans .

Depuis la création par Olivier Meunier de l’architecture qui sous-tend les fonctionnalités d’inspection automatique d’Opquast Reporting (OR pour les intimes), nous souffrons de temps à autre de ralentissements. Je vais rapidement vous expliquer ce qui se passe et ce que nous prévoyons pour les toutes prochaines semaines. Si vous n’avez pas le profil technique, sachez juste que de grosses améliorations sont à venir, et si la technique vous intéresse, voici quelques explications.

Un gros chantier : les performances

Les inspections automatiques effectuées avec Opquast reporting mobilisent notamment notre add-on Open source Firefox Mephisto. Pour améliorer les performances des inspections, nous avons multiplié les instances mobilisées, nous avons pris des serveurs supplémentaires, supprimé les tests les plus longs, et mis au point une architecture technique très solide à base de machines virtuelles. Dans le même temps, nous avons mis en place des caches à plusieurs niveaux, ce qui fait que les performances de l’application Opquast reporting se sont considérablement améliorées.

Il reste tout de même un goulet d’étranglement. Opquast reporting repose sur la base de données MySQL pour l’application en elle-même, et sur la base de données MongoDb pour le stockage des données et des ressources inspectées automatiquement. De temps en temps, sur certains sites et malgré ces précautions, la masse de données renvoyées vers MongoDB lors de certaines inspections a tendance à ralentir le serveur.

Une base de données pour les gouverner tous

Pour cette raison et d’autres liées à la rationalisation de notre architecture, nous avons décidé de basculer l’ensemble de nos données sur une base de données unique, et c’est PostgreSQL qui a été choisi. Ce choix a plusieurs conséquences pour l’équipe technique du projet. Celle-ci a du optimiser certains aspects de l’application, comme la rationalisation des tags ou le nettoyage de toutes les données non utilisées. Les deux prochaines semaines vont être passées à préparer la mise en place de la nouvelle architecture et la migration de toutes les données vers PostgreSQL.

Qu’attendre de ces améliorations ?

En tant qu’utilisateurs finaux, vous pouvez vous attendre à de meilleures performances, une meilleure stabilité, mais surtout à l’arrivée de nouvelles fonctionnalités et API dans les prochaines semaines. Sur le plan de l’architecture, il nous restera un dernier gros chantier autour du format des tests utilisés par l’application, mais c’est une autre histoire et je vous en reparlerai un peu plus tard.