[rabbitmq-discuss] Introducing Rabbitbal
dmitriy.samovskiy at cohesiveft.com
Thu Dec 18 16:02:57 GMT 2008
>> In case anybody is interested in a rabbitmq-based reverse proxy for rails, I put one
>> together at http://github.com/somic/rabbitbal. The README file explains possible benefits
>> of using AMQP instead of raw HTTP in proxy scenarios as I see them. This is proof of
>> concept, not thoroughly tested under load.
> Interesting. Just out of interest's sake, what effect does the latency
> of delivery have in comparison to using a plain jane reverse proxy?
To be honest, I don't know if latency of delivery in rabbitbal will be better or worse
than in regular proxy. I think it will be pretty much the same. Also, note that latency of
delivery is relatively small part of entire request-response cycle in HTTP these days,
esp. in reverse proxy scenarios where proxies are usually close to servers.
Latency imho is not a driver for rabbitbal. More efficient load balancing is.
> Also, would this not be a use case for the qos command - do you have
> a real scenario where the processing time differs across requests or
> just across each backend?
Once we take a request from "HTTP wire" and put it on "AMQP wire", we can definitely use
all sorts of load balancing facilities provided by RabbitMQ. There is no reason why
basic.qos won't help at least on some workloads.
Different hardware (for example) can lead to processing time differing between backends;
if one request leads to a single simple SQL and another has tons of difficult ones, this
would obviously lead to different processing times across requests.
More information about the rabbitmq-discuss