How do you manage connections? Do you use keep-alive or not? If so, you have some sort of connection pool mechanism in order to be able to perform requests in parallel? These two problems is the main reason for why I switched to a MQ instead of using HTTP.
(Hopefully I managed to not make this seem like flaming, I'm genuinely curious.)
I think it was meant that switching to 0MQ instead of HTTP provides little benefit at this stage for that person. The great thing about HTTP is that you can quickly whip up services that will work without worrying about performance until later. I'm sure the same thing can be said about 0MQ once you are fluent in it, but it is not ubiquitous as HTTP.
In other words, it can be considered a premature optimization
Note that HTTP pipelining will let you have multiple outstanding HTTP requests on the same TCP connections, although it comes with some caveats: http://en.wikipedia.org/wiki/HTTP_pipelining
@augustl: We manage connections with curl and requests(python). We haven't seen any bottlenecks here yet, so we haven't thought to revisit it.
We do, however, use ZeroMQ for other stuff. But I'll always reach for HTTP for an API, unless there's a need to do otherwise. It's super simple to get running, interface and debug with. Every backend engineer knows how to use curl.
This. 0MQ is an optimisation and as everyone knows, these optimisations should be delayed until the last minute.
We're still shifting services over HTTP off a mix of Apache and IIS boxes. We can do 80 million service requests a day without hitting 5% of our capacity with commodity hardware.
These service requests are extremely complicated calculation and scoring algorithms as well so not some half-arsed CRUD API either.
We just do it in C# and C++ rather than Python/Ruby etc as that's where we gain the performance advantage.
