A hyper update
A new version of hyper was released last week, v0.10.0, to fix a lot of dependency-related problems that the 0.9 versions were having. The biggest problem was version incompatibilities with OpenSSL. You can read all about the problem and solution in the issue tracker, but the tl;dr is that hyper 0.10 no longer depends on OpenSSL, or any TLS implementation really. TLS is a big part of HTTP, but there are also several different implementations, and they all release on their own schedules. Even just an optional dependency on OpenSSL could cause unrecoverable dependency conflicts.
This should be the last feature release of hyper using blocking IO. You can sort of think of it as an LTS version. If there are serious bugs or security fixes, a point release will be made. But all development is completely focused on the new release that will be using tokio. Speaking of…
hyper and tokio
The work to make hyper use non-blocking IO has been a long road. In recent months, it has been with the help of the tokio library, which just recently released a version. We just merged the tokio branch into master this week!
wrk -t 10 -d 10s -c 20: 225759.00 requests per second1
The full pipeline works great, and it’s fast!2 Using futures feels very natural when programming with the asynchronicity of HTTP messages. Instead of including inline code examples here that may grow stale, I’ll just point to the examples in the hyper repository. And yes, full guides will be coming soon, as part of the 0.11 release.
There’s still things to touch up. We’re still trying to find the best ways to a) setup an HTTP server or client for easy use, b) plug in an HTTP server or client into a the wider tokio ecosystem. There’s still internal performance things we could do to get even faster. But there’s a light at the end of this tunnel. It’s growing. If you’d like, join in! Or try to port your framework to use it, and provide feedback.
Soon, we’ll have a much better answer for are we web yet?
The benchmarks are hand-wavey at the moment. I surprisingly don’t have an environment available to me to benchmark a bunch of different settings and against other HTTP libraries. If you’d like to help record some benchmarks, I’d greatly appreciate it. ↩︎
Of course, the biggest benefit of non-blocking IO is that it is the best way to scale when you have other IO to do in order to serve a request (files, databases, other networking, etc), or when the payloads are bigger than the the network packet size, and you want to serve thousands of those requests at the same time. ↩︎