Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upUpgrade to `tokio v0.2` and `std::future::Future` #1142
Comments
This comment has been minimized.
This comment has been minimized.
|
cc @hawkw I know you've been working on some of these blocking issues but there might be more info here that you find interesting and could be helpful. |
This comment has been minimized.
This comment has been minimized.
|
Sounds great! I think the compat runtime is definitely the way to go. If we can slip it in with minimal changes, we can start to run some tests against that diff alone before tackling any conversions.
It looks like this link is broken. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
Current runtime and futures version
Originally, when we first started working on
vectoronlyfutures 0.1andtokio 0.1was released. There was no language level support for futures norasync/await. In that time since we first started working on vector, we have seen the addition ofstd::future::Future,std::task::{Context, Poll}, and theasync_awaitfeature (which lands on stable Nov 7th).Async/await itself is a huge shift in how we write futures and in my experience has reduced the amount of code by up to 40-60%. The biggest benefit is that it allows us to write more "rusty" code because we can now borrow accross yield points which was not possible before without a lot of work.
Tokio 0.2
As some of you may have seen
tokiohas recently implemented a new scheduler along with its upgrade fromfutures 0.1tostd::future::Future. This new scheduler has a couple of improvements that impact us directly. Notably less aggressive work-stealing and better optimizations around sendings on channels. You can read more in thisblogpost.The biggest issue with moving to
tokio 0.2will be the fact that we have a lot of code that usestokio-reactor 0.1. Alltokio 0.2runtimes do not provide access to this reactor and thus our code will not work if we just swap out runtimes. To fix this issue the tokio team has written atokio-compatruntime which uses thetokio 0.2executor/scheduler,tokio-net(which is the new reactor for 0.2),tokio-timer 0.2and a backgroundtokio-reactor 0.1/tokio-timer 0.1. This allows us to execute futures that are written in bothfutures 0.1andstd::future::Futureas well as futures that are fromtokio 0.1andtokio 0.2.Performance
During my benchmarking this weekend I was able to see up to
6xperformance increases and on average at least a 100% increase in performance in just upgrading the executor totokio 0.2.Benchmarks comparing
tokio v0.1.22andtokio-compat rev f64aee/tokio rev e699d4653Note: tests with a change +/-5 were ignored.
A
c5.4xlargewas used. Code can be found here https://github.com/timberio/vector/tree/lucio/compat-benchSome of these performance numbers are extremely good and slightly confirm some of the theories we've had about certain performance issues that we've seen with
vector.Proposal
I suggest that we start moving to the
tokio-compatruntime which will allow us to supporttokio 0.1andtokio 0.2items. This will also enable us to spawnstd::future::Futureandfuture 0.1futures at the same time. This should then allow us to incrementally move to the new futures version and async/await.The actual code change can be done in about 10 lines of code since we already refactored the runtimes out in #1098. That said there are a few blockers:
filesink will need a rewrite since it usestokio 0.1blocking annotations which are not currently supported intokio-compat. This is probably the biggest change that we will need but the sink is very new and I don't think its in a very mature state like some of our others. I have a couple ideas how to refactor this sink easily but it should not be much work since the sink is very simple.tokio_threadpool::blockingis used which will not work intokio-compat. We can just upgrade these to the newtokio::executor::thread_pool::blockingfn that was added recently.Topologly::stopto use our own shutdown mechanism.tokio 0.2will not provide the sameshutdownapi thattokio 0.1did. Our current shutdown code andTopology::stopimplementation has already show some issues and this would be good to combine with #1091.Beyond these few blockers, I was able to run almost all our tests and most of our benchmarks this weekend with no changes done to them.
Before we move to this new runtime I would also like to ensure that we run it under a week of validation using @lukesteensen's reliability work and run it against our test harness that @binarylogic wrote.
You can look here to see how easy it was to move to the new runtime d56a945
This content would also be a great technical blog post talking about how the new executor improved performance and other novel rust futures-based things.
cc @a-rodin @Jeffail @lukesteensen @binarylogic