On Friday, January 21, 2011 11:51:04 AM UTC, SleepyCal wrote: > > Yeah, but this is for server side only, so the internal webapps can talk to > each other. > > I guess the main question is, would a message queuing systems (such as > rabbitmq) combined with AMQP be more appropriate for these sorts of tasks? > The webapps themselves need to respond within 0.5 - 1.0 seconds, the > target average response time, so the method used by PHP and Python to talk > to each other would need to be efficient (i.e. as little overhead as > possible). >
No, message queues are not appropriate for synchronous requests. Some queueing systems can be made to run synchronously, but that's not really what they're for. I've recently finished a project where we rewrote an entire PHP system in Python. We did it in stages, and there was a significant amount of time where much of the website code was still in PHP while the backend was running Python. We approached this by splitting up the backend into a series of web services, which could be queried by both PHP and Python - the services either ran Django or one of the smaller Python microframeworks, but the common point was that they all exposed REST interfaces and returned JSON which could be consumed by the frontend. It turned out to be a good thing to split up the services in any case, because that gives us all kinds of flexibility when it comes to scaling. -- DR. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
