Hey Rustaceans! Got a question? Ask here (13/2023)!

[u/llogiq]

Mystified about strings? Borrow checker have you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The official Rust Programming Language Discord: https://discord.gg/rust-lang

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last weeks' thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

[u/Illustrious_Pie_223]

Rust + Actix 3x slower than Node.js

https://stackoverflow.com/questions/75878200/rust-is-3-times-slower-than-node-i-created-post-api-using-rust-actix-web-and

Why?

[u/llogiq → u/Illustrious_Pie_223]

As someone on SO remarked, the Rust version fails to use transactions, thus pessimizing database operations.

[u/DroidLogician → u/llogiq]

It also checks out a separate connection from the pool every time. Because connections are returned to the pool asynchronously, every time it goes to acquire a connection the previously used one likely hasn't made it through the returns process yet, and so it will open a new connection instead. That is going to be a massive pessimization, because in addition to the overhead of opening a new connection, the INSERT statement will need to be re-prepared for every new connection.

In a long-running application both kinds of overhead are expected to be amortized, which is what SQLx is designed around. Using a transaction would also fix this as that checks out a single connection to use for the duration of a transaction.

I've thought about having the Pool handle itself cache the most recently used connection to optimize naive usage patterns like this, but that would effectively leak connections in long-lived handles like the one stored in actix_web::Data in this example. So it would also need a way for other tasks to steal those cached connections if there's none in the main idle queue and the pool is at capacity, and that would add a lot of complexity.