Thanks for the video. While I agree with the conclusion (often async is not necessary), the benchmarks are a bit misleading. As long as no I/O bound things are executed (like DB access, network access or file access) and only CPU bound things (json serialization), async brings no performance advantage. ... So a (more realistic) benchmark where each request executes a DB call (which takes 50ms) would be interesting.
The source code for wrk is here, btw: github.com/wg/wrk/ The C10k problem is actually less of a problem these days because operating systems are much faster than they used to be. There's no special case needed for Rust.
Is Async not needed because that library converts a struct to a json string too fast? What will happen if we sleep for 500ms in each request? I really want to try it by myself but my Rust level is not enough to write such a simple Rust file 😞
The latency is impacted much more than the throughput, although the picture is unclear from short benchmarking runs. If you sleep for 500ms in each request, it severely impacts performance using the benchmarking system that we're using. If you increase the concurrency parameter, you can still easily reach 1000 reqs/sec though, e.g. `wrk -t 4 -c 1000 localhost:10000`.
@@timClicks Then in real life, we still need async/reactive or virtual/green thread (like in the Java project Loom) as each request will need to talk to the db or other services. (i.e. each request needs about 2-300ms to finish). Is that correct? If yes, what's Rust solution for serving a lot of requests which spend more time in waiting than in computing stuff?
No, not necessarily. That's the point of the video. In the case that you're accessing a backend service, such as a database, your thread will simply block and consume no resources. If you're convinced by the async model, then I recommend frameworks that are build on top of the Tokio project, such as Axum and Actix Web.
@@avalagum7957 the thumb rule is to use async programming for something that can block (io) and thread programming for something that needs the cpu (computations)
Thanks for the video. While I agree with the conclusion (often async is not necessary), the benchmarks are a bit misleading. As long as no I/O bound things are executed (like DB access, network access or file access) and only CPU bound things (json serialization), async brings no performance advantage. ... So a (more realistic) benchmark where each request executes a DB call (which takes 50ms) would be interesting.
Very nice framework. I like minimalistics to embed in other devices. Will read about rouille
TIL wrk! This was great!
is there an analog for this for the C10k problem in rust?
The source code for wrk is here, btw: github.com/wg/wrk/
The C10k problem is actually less of a problem these days because operating systems are much faster than they used to be. There's no special case needed for Rust.
struct JamJar { volume: Oz }
Is Async not needed because that library converts a struct to a json string too fast? What will happen if we sleep for 500ms in each request? I really want to try it by myself but my Rust level is not enough to write such a simple Rust file 😞
The latency is impacted much more than the throughput, although the picture is unclear from short benchmarking runs.
If you sleep for 500ms in each request, it severely impacts performance using the benchmarking system that we're using.
If you increase the concurrency parameter, you can still easily reach 1000 reqs/sec though, e.g. `wrk -t 4 -c 1000 localhost:10000`.
@@timClicks Then in real life, we still need async/reactive or virtual/green thread (like in the Java project Loom) as each request will need to talk to the db or other services. (i.e. each request needs about 2-300ms to finish). Is that correct? If yes, what's Rust solution for serving a lot of requests which spend more time in waiting than in computing stuff?
No, not necessarily. That's the point of the video. In the case that you're accessing a backend service, such as a database, your thread will simply block and consume no resources.
If you're convinced by the async model, then I recommend frameworks that are build on top of the Tokio project, such as Axum and Actix Web.
@@avalagum7957 the thumb rule is to use async programming for something that can block (io) and thread programming for something that needs the cpu (computations)
If the thread blocks, it can no longer serve requests, right?