Même si c'est certainement pas optimal, je n'ai pas envie de gérer une historisation complète dans redis dans la mesure ou out est copier en ram indéfiniement et que j'aimerai virer les éléments vieux de la ram et les garder juste pour de la consultation occasionnelle.
Je pense que ce sont des serveurs et au final, maintenant, je me demande si j'ai vraiment besoin d'un programe intermédiaire pour les faire discuter. Tornado a un client http asyncrone et faire un webservice même si ce n'est pas optimal doit être plus simple en terme d'architechture. http://www.tornadoweb.org/documentation/httpclient.html Merci de votre aide, Redis aurai pu être une très bonne solution notament en terme de performance brute et ça n'aurai pas couté de service en plus en substituant rabbitmq. Cordialement, Christophe. 2012/7/25 Kevin Samuel <[email protected]> > +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 > -- Best regards, Christophe Narbonne http://blogs.dotnet-france.com/christophen/
_______________________________________________ django mailing list [email protected] http://lists.afpy.org/mailman/listinfo/django
