3 ms·

We already have the actor model in Rust, via threads. Some people want better performance than what threads can provide. M:N was tried in Rust and the performan

We already have the actor model in Rust, via threads. Some people want better performance than what threads can provide. M:N was tried in Rust and the performance was found to be insufficient (and there were other downsides too). So async/await was the next best option. If you want the actor model, you can use it! There is nothing stopping you from going thread-per-connection in Rust. It's quite fast on Linux for all but the most demanding workloads. If I were writing an ordinary network service expecting moderate traffic, I'd probably go thread-per-connection.

tombert 7y ago
I'm actually asking this sincerely; hasn't this experiment already been run with Apache vs. Nginx, with Nginx coming out literally orders of magnitude faster by using epoll and using a limited number of "real" threads?
- Scarbutt 7y ago
  Maybe, but for most websites Apache was never the bottleneck, it was more than enough, which is I think the point GP is making.
- markdog12 7y ago
  > I'm actually asking this sincerely Why do you have to say this?
  - tombert 7y ago
    Because on the internet it can be difficult to tell the difference between someone asking the question as some kind of "gotcha!" and between someone asking a legitimate question. I tend to be a fairly sarcastic person so when I want to make sure it's unambiguous that I'm not, I prefix my questions.
- pcwalton 7y ago
  The performance differences between Apache and nginx are attributable to more than that one design decision. Besides, Apache is fast enough for most use cases.
- skybrian 7y ago
  Well, it depends what else the server is doing besides talking to the network. Low-overhead concurrency matters when you're basically just copying data to the network, like serving up static HTML, images, or video. Particularly when clients have slow network connections, a request can take a long time with nothing much happening on the server. If most requests are mostly idle, the server can handle many more concurrent requests with lightweight concurrency. With heavyweight computations, CPU usage will hit 100% with a small number of concurrent requests, so a thread per request will work fine. Your server will get overloaded before you have too many threads and that load needs to be shed somehow, maybe by putting more servers online. Even if you're using async-await, using threads for heavyweight requests is recommended anyway. An async function isn't supposed to hog the CPU; instead you outsource to a thread pool.

tombert 7y ago

I'm actually asking this sincerely; hasn't this experiment already been run with Apache vs. Nginx, with Nginx coming out literally orders of magnitude faster by using epoll and using a limited number of "real" threads?

Scarbutt 7y ago
Maybe, but for most websites Apache was never the bottleneck, it was more than enough, which is I think the point GP is making.
markdog12 7y ago
> I'm actually asking this sincerely Why do you have to say this?
- tombert 7y ago
  Because on the internet it can be difficult to tell the difference between someone asking the question as some kind of "gotcha!" and between someone asking a legitimate question. I tend to be a fairly sarcastic person so when I want to make sure it's unambiguous that I'm not, I prefix my questions.
pcwalton 7y ago
The performance differences between Apache and nginx are attributable to more than that one design decision. Besides, Apache is fast enough for most use cases.
skybrian 7y ago
Well, it depends what else the server is doing besides talking to the network. Low-overhead concurrency matters when you're basically just copying data to the network, like serving up static HTML, images, or video. Particularly when clients have slow network connections, a request can take a long time with nothing much happening on the server. If most requests are mostly idle, the server can handle many more concurrent requests with lightweight concurrency. With heavyweight computations, CPU usage will hit 100% with a small number of concurrent requests, so a thread per request will work fine. Your server will get overloaded before you have too many threads and that load needs to be shed somehow, maybe by putting more servers online. Even if you're using async-await, using threads for heavyweight requests is recommended anyway. An async function isn't supposed to hog the CPU; instead you outsource to a thread pool.