Nucleon, a dynamic TCP load balancer written in Rust(github.com)
github.com
Nucleon, a dynamic TCP load balancer written in Rust
https://github.com/NicolasLM/nucleon
24 comments
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 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.
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..
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..
I'm surprised that dynamic backend management is based on Redis. This seems very heavyweight. Why not just a simple HTTP API?
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.
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'd bet Redis is actually lighter weight than an HTTP request
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)
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 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.
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?
That's more what I was getting at, not "heavyweight" in the sense that I see it as a performance concern.
What happens if your connection to redis dropped and a pub was made in between?
What not NATS instead? There's even a very nice Rust client library for NATS :)
Is putting the unit-tests inline with the code standard best practice in rust?
Overall it's an interesting project and seems like a nice showcase of actual rust src code.
Overall it's an interesting project and seems like a nice showcase of actual rust src code.
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".
Thanks for explaining. I definitely like the pattern accounting for integration tests! That is really nice.
Combined with dns SRV lookups it could be a nice alternative to connectable [0].
[0] https://github.com/gliderlabs/connectable
[0] https://github.com/gliderlabs/connectable
Great performance numbers, specially seeing that it only uses a single thread.
hmm.. nice and small .. trying this out now for some internal socks5 hacks
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.