(I'm a bit confused why you have a 370MB docker image with the complete rust compiler though, I expected it to be ~20MB with nothing but busybox, openssl and one the linkerd-tcp binary in it.)
Really, because we rushed to push something before a talk I gave this week. We'll definitely need to fix this. As always, pull requests are encouraged!
Yeah! Really want to do this for our Rust images. Any chance you could point me to a canonical way of building and packaging static rust binaries into docker images? We do something similar for all of our Go packages, but I couldn't quite figure it out with Rust in time for the launch. We'll definitely fix this though.
Yep, this is the way to go: Build a Docker image in your Docker build container (+/- a few buzzwords). You might even try to build it statically targeting musl instead of glibc, which is more tricky depending on the external libraries you use, but will work with the ESM slimmer alpine image and, without Docker, on every native Linux.
As someone who's not very familiar with the JVM ecosystem, I've heard of Finagle, in particular how Tokio was inspired by it, but I have no real experience with either. How would you compare your experience with the two?
They are "spiritually" similar, but practically, quite different.
I should note, linkerd-tcp only uses tokio-core and not the higher-level tokio-service. This distinction is roughly analogous to Netty and Finagle: tokio-core provides the underlying transport utilities, while tokio-service provides more application-facing affordances.
Furthermore, Rust's ownership, threading, and type systems are obviously quite different from that of the JVM, and there's really no way around that. But, based on my initial experience, tokio seems like a project very much headed in the right direction.
Awesome to see. Linkerd has a pretty aweseome design but pulling in the entirety of the JVM for that always felt really questionable to me. This makes it a lot more attractive.
It's not fair to compare linkerd-tpc and linkerd -- the projects have quite different goals, but both work well as a complementary suite of tools.
So far latency has been comparable with other native load balancers: we've built performance profiles for nginx proxy_pass and haproxy to compare against although as we add features our numbers are starting to come down a bit.
We're still building our collection of tools for tracking down performance issues like lock contention, allocation hotspots, etc. We've had good luck finding cpu hotspots with linux perf and valgrind but less luck tracking down mutex holders and allocation hotspots. Any advice is welcome!
Getting past the handshake was quite difficult (a lot of tcpdump and trial-and-error), and I suspect my solution may have some bugs. Other than that, quite easy.
That looks alright to me. But yes, the IO-free interface can make it annoying to get started. tokio-rustls might be a good option if it fits in with your uses though.
tokio-rust uses the higher-level tokio-proto and for the initial work, I was trying to only use tokio-core. I'll definitely take a look at how we can merge things moving forward. Thanks for the pointer!
👋 I'm the creator of linkerd. Happy to answer any questions.
Nice!
(I'm a bit confused why you have a 370MB docker image with the complete rust compiler though, I expected it to be ~20MB with nothing but busybox, openssl and one the linkerd-tcp binary in it.)
Really, because we rushed to push something before a talk I gave this week. We'll definitely need to fix this. As always, pull requests are encouraged!
Yeah! Really want to do this for our Rust images. Any chance you could point me to a canonical way of building and packaging static rust binaries into docker images? We do something similar for all of our Go packages, but I couldn't quite figure it out with Rust in time for the launch. We'll definitely fix this though.
I ended up going with: https://github.com/linkerd/linkerd-tcp/pull/20
Yep, this is the way to go: Build a Docker image in your Docker build container (+/- a few buzzwords). You might even try to build it statically targeting musl instead of glibc, which is more tricky depending on the external libraries you use, but will work with the ESM slimmer alpine image and, without Docker, on every native Linux.
As someone who's not very familiar with the JVM ecosystem, I've heard of Finagle, in particular how Tokio was inspired by it, but I have no real experience with either. How would you compare your experience with the two?
They are "spiritually" similar, but practically, quite different.
I should note, linkerd-tcp only uses tokio-core and not the higher-level tokio-service. This distinction is roughly analogous to Netty and Finagle: tokio-core provides the underlying transport utilities, while tokio-service provides more application-facing affordances.
Furthermore, Rust's ownership, threading, and type systems are obviously quite different from that of the JVM, and there's really no way around that. But, based on my initial experience, tokio seems like a project very much headed in the right direction.
Awesome to see. Linkerd has a pretty aweseome design but pulling in the entirety of the JVM for that always felt really questionable to me. This makes it a lot more attractive.
I'm so excited to see this!
Are you all interested in being on the friends page? If so, there's a link to a form at the bottom :)
Do you have benchmarks, and/or production numbers comparing how Rust helped performance, memory footprint, lines of code, etc?
It's not fair to compare linkerd-tpc and linkerd -- the projects have quite different goals, but both work well as a complementary suite of tools.
So far latency has been comparable with other native load balancers: we've built performance profiles for nginx proxy_pass and haproxy to compare against although as we add features our numbers are starting to come down a bit.
We're still building our collection of tools for tracking down performance issues like lock contention, allocation hotspots, etc. We've had good luck finding cpu hotspots with linux perf and valgrind but less luck tracking down mutex holders and allocation hotspots. Any advice is welcome!
Is there anything you want that's missing from rustls? Or that you found annoying or unergonomic?
Getting past the handshake was quite difficult (a lot of tcpdump and trial-and-error), and I suspect my solution may have some bugs. Other than that, quite easy.
That looks alright to me. But yes, the IO-free interface can make it annoying to get started. tokio-rustls might be a good option if it fits in with your uses though.
tokio-rust uses the higher-level tokio-proto and for the initial work, I was trying to only use tokio-core. I'll definitely take a look at how we can merge things moving forward. Thanks for the pointer!