haproxy can be configured in so many ways. Without providing your haproxy config and testing environment these numbers won't make sense.
For example, configure haproxy with tcp splicing, and now you eliminated all the userland/kernel copies between client/server, and haproxy goes as fast as your kernel + network IO can go.
Nicolas from Nucleon here. You are right, I probably shouldn't have put these numbers there as haproxy can be configured way better than it is with its default configuration.
I put them because I was impressed that Rust and mio, with little to no optimization, can compete with the best softwares out there.
I think it's useful to to have "untuned HAProxy" as a reference benchmark, to have a goal to measure pre-1.0 development progress against. When a project hits that order-of-magnitude of speed, you can assume it isn't screwing anything major up in its design.
I am not saying to tune HAProxy to win the benchmark. When you want to compare, it's a good idea to compare apples to apples.
Like I said in my previous comment, HAProxy is a doing a lot more than what it's being compared with. HAProxy has timeout schedulers that are activated on every packet received, maintain stats, logging, and a lot more.
When proxying network IO, there's not much that the language is doing. The burden is more on the OS.
However, the comparison is not fair because what you are doing is just passing data in and out while haproxy is running a scheduler to maintain timeouts, logging, checking acl rules on connection establishment, maintaining stats, etc..
While I'm sure someone, somewhere in the world has it, it would be an odd use case where the "heavyweightness" of the run-time configuration interface actually matters to anyone.
And, well, actually, if I had to bet, I'd bet Redis is actually lighter weight than an HTTP request, honestly. HTTP is really quite inefficient for small requests, and requires a massive pile of code to deal with endless, endless corner cases than an application-specific protocol doesn't.
I wouldn't compare Redis pub/sub on a persistent Redis socket to straight HTTP requests; it's more like an HTTP Server-Sent-Event stream, which looks pretty similar at the protocol level.
Redis in Pub/Sub is quite lightweight in fact. It's just a TCP connection between your application and the Redis database. Once opened, you can get notifications almost for free.
I was thinking on adding a separate HTTP API to control the load balancer that would read and write to Redis, notifying the load balancer when changes should be applied.
But it's a SPoF and an extra remote or local service that has to be configured, maintained, etc. The thing that's coming online has to publish a message to redis anyway, so why not just maintain the service map inside the Rust application and open up a socket that allows those things to speak straight to Nucleon for mutating its configuration?
Yeah, it's one of the methods supported by Cargo. You can put them in the code or in separate modules. Cargo will also test your documentation examples. :-D
Yes, the pattern used here is usual. However, you can also pull any module out to another file, if it gets too big. But the pattern is "Unit tests with the code, integration tests in a separate tests directory".
24 comments
[ 5.0 ms ] story [ 65.5 ms ] threadFor example, configure haproxy with tcp splicing, and now you eliminated all the userland/kernel copies between client/server, and haproxy goes as fast as your kernel + network IO can go.
I put them because I was impressed that Rust and mio, with little to no optimization, can compete with the best softwares out there.
Like I said in my previous comment, HAProxy is a doing a lot more than what it's being compared with. HAProxy has timeout schedulers that are activated on every packet received, maintain stats, logging, and a lot more.
However, the comparison is not fair because what you are doing is just passing data in and out while haproxy is running a scheduler to maintain timeouts, logging, checking acl rules on connection establishment, maintaining stats, etc..
And, well, actually, if I had to bet, I'd bet Redis is actually lighter weight than an HTTP request, honestly. HTTP is really quite inefficient for small requests, and requires a massive pile of code to deal with endless, endless corner cases than an application-specific protocol doesn't.
It is.
Here's a cool, non-relevant example of one implementing a Redis clone in Haskell (on HN a month or so ago):
https://honza.ca/2015/09/building-a-redis-clone-in-haskell
The relevant portion is where they parse the protocol, not bad at all (especially compared to HTTP)
I was thinking on adding a separate HTTP API to control the load balancer that would read and write to Redis, notifying the load balancer when changes should be applied.
[0] https://github.com/gliderlabs/connectable
Overall it's an interesting project and seems like a nice showcase of actual rust src code.