I found this site that ran some benchmarks on different web framework. If you look at all the latency data, nickel.rs is at the top of all the statistics for their tests. I was wondering how does nickel handle latency so well compared to other frameworks.
I also found this site that showed benchmarks on the speed of different web frameworks. May-minihttp is at the fastest framework according to their statistics, so I was wondering, what makes it so fast?
I understand benchmarks are dependent on machine and not always 100% accurate, but I was curious about the results.
nickel v0.11 (which is a legacy framework that hasn't been updated in several years) might have a low latency, but it also handles fewer requests than current frameworks like axum, actix-web or warp. It is still synchronous, which I assume is the reason for the lower latency and requests per second.
Ok thank you so much for the help. How do frameworks like actix-web handle that many requests compared to other frameworks, and is there any good bench mark tests you would recommend for web frameworks?
They are build on top of the tokio asynchronous runtime which is very fast for network IO.
The one you cited is probably the most popular one. Or at least I've seen it pop up the most when people are comparing the performance of web frameworks. I wouldn't put too much weight on the results though. Actix-web, axum, warp, Rocket, they are all more than fast enough and the only real performance difference when it comes to the benchmarks is how much optimization effort people have put into the code for the benchmark.
Note that there's a general tradeoff between latency and throughput (requests per second); an idle CPU can respond very quickly to an incoming request, but idle CPUs mean that you could do higher throughput if you could avoid those CPUs going idle.
On the other hand, if all CPUs are busy serving requests, while you have throughput, you now have to wait for a CPU to be available before you can handle a request, increasing latency. Async runtimes as used by actix-web, axum, warp and rocket make the decision to keep all CPUs busy (=> more RPS), at the expense of a latency penalty.
Alice Ryhl and a cohort of other great devs that know a lot about making network IO go brr
Asynchronous IO is better in serving a lot of connections simultaneously and keep the CPU utilized, as it allows you to perform computation as the data becomes available over the network. That reduces the time of idle CPU time as you can serve a different connection (if it's data becomes available), while the first connection waits.
I rarely work in an environment where performance is the deciding factor on web frameworks; I therefore have no strong opinions on "best performance-wise", since I mostly care about performance once you've scaled out (which implies there's load balancers etc involved), and there, the differences between individual frameworks are in the noise.
My preferences come down to ease of writing a good, reliable application that interacts nicely with the rest of the system - I like axum as a framework that seems to make good choices for my needs.
It goes a bit further than that - if you get data available for two clients at once, you can serve them both from the same Tokio worker thread, one after the other, instead of losing CPU time to context-switching between threads, or between application and kernel.
This is where the latency penalty comes from, since you're processing two (or more) clients in series on a single CPU thread, but it comes at a throughput gain, since you're not spending time on context switches, but instead processing all the data in one big run.
