6 ms·
HTTP works fine for me. Seems like a nice article though.
by sauravc 13y ago
HTTP works fine for me. Seems like a nice article though.
- augustl 13y agoHow 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.)
- mathrawka 13y agoI 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
- friism 13y agoNote 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 http://en.wikipedia.org/wiki/HTTP_pipelining
- tszming 13y agoHave you considered/tried using a decent HTTP client + HAProxy?
- augustl 13y agoI have, but the fundamental limitation of sequential req/rep on a connection with HTTP pushed me to find alternatives. Do you have any recommendations for decent HTTP clients?
- sauravc 13y ago@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.
- harrytuttle 13y agoThis. 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.