+1 pour utiliser redis comme moyen de sync entre tous les dispositifs: très rapide, atomique, persistent.
Le mer. 25 juil. 2012 13:04:59 CEST, Aymeric Barantal a écrit : > > Le 25 juil. 2012 à 11:37, Christophe Narbonne a écrit : > >> Bonjour, >> >> Pour mes application temps réel, je complète django avec tornado qui a son >> moteur d'évènements. Ma difficultée est que je n'accède à mes données que >> par l'orm de django et notification entre mon serveur django et mon serveur >> tornado. Pour l'instant, pour limiter les accès bloquants, je charge les >> dernières données au lancement du serveur tornado (pas génant qu'il y ait >> une procédure bloquante à ce moment) puis je la tien en mémoire sous forme >> de listes python. (plus exactement un dictionnaire de listes qui sont gérées >> comme des queues FILO). >> >> Ce que je ne trouve pas et que je cherche c'est un moyen d'avoir un mixin ou >> un monkeypatch pour mes modèles django pour que les appels db soient >> asyncrones. > > Hello, > > C'est le driver DB qu'il faut changer pour en mettre une version gérant les > sockets en asynchrone. > > La lib mysql en C utilisée par MysqlDB n'est par exemple pas du tout > asynchrone, le monkey patch ne > peut fonctionner. > > psycopg2 a un mode async possible, mais j'ai jamais expérimenté et ne peut en > dire plus. > >> >> En espérant une piste car la gestion en mémoire des queues me limite à un >> seul process. > > Utiliser un système de cache memcached / redis (avec les inconvénients a bien > le gérer) > partagé entre Django (qui rafraichit le cache) et Tornado. > > La gestion async d'un tel composant étant bien plus évidente qu'une DB. Par > contre c'est > un composant supplémentaire dans l'architecture, ce n'est peut être pas > souhaité. > >> >> Note: mon serveur django utilise déjà celery et dans les pistes que je n'ai >> pas exclues mais que je trouverai domage car redondente avec ce service, ce >> serait d'utiliser zmq (ou pika) pour toutes les taches faisant un accès db. >> puis utiliser un autre broker unique pour gérer en mémoire mes queues ce qui >> permetrait de répartir après le service tornado sur plusieur process. > > pour de l'async sur de l'AMQP je préconise plutôt puka que pika. Il est > dommage que la version récente de pika ne soit plus compatible avec kombu > (composant bas niveau de celery pour la gestion des > différents protocoles de message queuing). > >> Après, j'ai pas non plus envie de faire de l'over engeneering... > > > ++ Aymeric > > _______________________________________________ > django mailing list > [email protected] > http://lists.afpy.org/mailman/listinfo/django _______________________________________________ django mailing list [email protected] http://lists.afpy.org/mailman/listinfo/django
