[znfi]

Not sure if I'm missing something, but for the Techempower Bencharks [1] I had the impression that the bottleneck for other rust libraries were in accessing the database rather than handling http requests. However, looking at the code [2] it seems that the Actix solution isn't doing anything special with regards to this. Can someone give a quick description of "what" is causing such a huge performance boost for Actix compared to other frameworks?

(I might add that this is a question I've had for a while, and I did not check the source at [2] in detail today.)

[1]: https://www.techempower.com/benchmarks/

[2]: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

[steveklabnik]

These kinds of tests are heavily reliant on having async IO, and https://news.ycombinator.com/item?id=17194761

[znfi]

Any chance you could elaborate on this, because I dont really understand how it answers my original question.

I have not checked recently, but last I saw, the database libraries for rust did not use async IO. Looking at (what I presume is) the code for the benchmark [1], it seems it imports the postgres and diesel crates. Last I heard diesel did not support async [2] and looking at the postgres crate [3] it does not mention async, which I assume it would in case it was supported.

My whole point was that, sure, I can see how async IO is important for handling many concurrent http requests, but each of those requests would still have to pass through the synchronous database driver which uses threadpooling, right? Or what am I missing here? I can see how it has great performance on the plaintext and json benchamrks, but I dont understand what gives it such a large boost in fortunes or multiple queries.

For example, Iron is doing 300k at plaintext/json benchmarks, but drops to 18k on fortunes, and the way I remember the benchmark code it is written in a fairly straight forward way. If the database layer supported 160k requests per second I dont see why we would see such a huge drop? (Edit: 160k is the performance of Actix on fortunes.)

I also recall seeing numbers on the 10k order of magnitude from doing naive benchmarks with the various database libraries available, without any http part to the application. But I'm not sure, maybe I'm missing something or remember incorrectly?

[1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

[2]: https://github.com/diesel-rs/diesel/issues/399

[3]: https://crates.io/crates/postgres

[steveklabnik]

> I can see how it has great performance on the plaintext and json benchamrks

I actually forgot the DB tests were implemented; when I was sending in PRs, I was mostly thinking about plaintext and JSON, not database stuff. Sorry about that!

However.

https://actix.rs/docs/databases/

> Technically, sync actors are worker style actors. Multiple sync actors can be run in parallel and process messages from same queue. Sync actors work in mpsc mode.

So, you're still getting some degree of parallelism here. I wonder if that's it?

(You're right about the fact that the DB APIs are currently synchronous.)

[fafhrd91]

Actix provides actor abstraction over synchronous code and allows to communicate with it in async manner. TechEmpower benchmarks uses sync actors for db operations and http part is async. I am not sure how this help though, tokio-minihttp also uses threadpool for db operations, results are not that good

[Ygg2]

From my cursory understanding there is following. There is a n async protocol for `postgres` crate called `tokio-postgres`[1] (it's a child crate that is enabled via feature). However, either only Postgres supports async protocols or there isn't an async protocol for Rust outside of `tokio-postgres`.

However, Diesel uses `libpq` over `postgres` (and its child crate `tokio-postgres`). Moving from `libpq` to `rust-postgres` would cause a lot of damage.

[1]https://github.com/sfackler/rust-postgres/tree/master/tokio-...

[fulafel]

If you are doing sql queries in web requests, you probably should not invest in Rust for performance.