
Nucleon, a dynamic TCP load balancer written in Rust - jsnell
https://github.com/NicolasLM/nucleon
======
halayli
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.

~~~
nicolaslem
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.

~~~
derefr
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.

~~~
halayli
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.

------
michaelmior
I'm surprised that dynamic backend management is based on Redis. This seems
very heavyweight. Why not just a simple HTTP API?

~~~
nicolaslem
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.

~~~
dave_ops
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?

~~~
michaelmior
That's more what I was getting at, not "heavyweight" in the sense that I see
it as a performance concern.

------
jaytaylor
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.

~~~
steveklabnik
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".

~~~
jaytaylor
Thanks for explaining. I definitely like the pattern accounting for
integration tests! That is really nice.

------
dave_ops
This has a redis service dependency? That is weird.

~~~
zaroth
As opposed to what, implementing your own proprietary control socket? Redis is
extremely compact and stable, and relatively tiny.

------
madbiz
Combined with dns SRV lookups it could be a nice alternative to connectable
[0].

[0]
[https://github.com/gliderlabs/connectable](https://github.com/gliderlabs/connectable)

------
arthursilva
Great performance numbers, specially seeing that it only uses a single thread.

~~~
joshbaptiste
hmm.. nice and small .. trying this out now for some internal socks5 hacks

