isn't flask inspired by a WSGI framework in ruby originally?
Like Sinatra?
Hum, yes, that is what the author says :)
Pencil: A Microframework Inspired by Flask for Rust
31–40 of 58 posts
Re: Pencil: A Microframework Inspired by Flask for Rust
#32Anyone know of any benchmarks? This seems to be built on top of hyper. I remember checking out hyper a couple months ago and being disappointed with its performance. Last I checked it was using synchronous IO, and was performing about an order of magnitude worse than equivalent Go. That could certainly change, but I'm hesitant to use Rust for an HTTP server like I would with Go until I see better performance.
Switching to asynchronous I/O isn't going to magically result in better performance on HTTP workloads. I don't think most of what any performance difference you're seeing is due to that: I suspect instead that it's relatively "boring" optimization work that has yet to be done in Hyper. The primary difference between async and synchronous I/O is (a) better memory usage due to not having a stack per connection; (b) you…
That's nice and all, but unfortunately the real world tests I've seen (and done) show something like Netty completely trumping anything available for Rust.
Re: Pencil: A Microframework Inspired by Flask for Rust
#33Earlier quoted context omitted.
Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. It's not a silver bullet, and can be very difficult to implement at the application layer to avoid blocking, but it will give markedly better performance.
But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. So you're not forced to store all the thread's stacks and you don't have expensive context switches. As the parent illustrated, even with Go using nonblocking I/O, it's perceived benefits in that area isn't that great because Go still semantically has a thread-per-connection. So the performance…
>But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model.
One reason, not the only, or the most important. The primary advantage of non blocking IO is that the CPU isn't sitting idle while waiting for an IO operation to complete. We aren't wasting an entire core to write the response.
Re: Pencil: A Microframework Inspired by Flask for Rust
#34Anyone know of any benchmarks? This seems to be built on top of hyper. I remember checking out hyper a couple months ago and being disappointed with its performance. Last I checked it was using synchronous IO, and was performing about an order of magnitude worse than equivalent Go. That could certainly change, but I'm hesitant to use Rust for an HTTP server like I would with Go until I see better performance.
Re: Pencil: A Microframework Inspired by Flask for Rust
#35That's a strange license to use
Re: Pencil: A Microframework Inspired by Flask for Rust
#36That's a strange license to use
CC is fine for docs.
Re: Pencil: A Microframework Inspired by Flask for Rust
#37Earlier quoted context omitted.
Switching to asynchronous I/O isn't going to magically result in better performance on HTTP workloads. I don't think most of what any performance difference you're seeing is due to that: I suspect instead that it's relatively "boring" optimization work that has yet to be done in Hyper. The primary difference between async and synchronous I/O is (a) better memory usage due to not having a stack per connection; (b) you…
Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. It's not a silver bullet, and can be very difficult to implement at the application layer to avoid blocking, but it will give markedly better performance.
>
Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io.
I know, of course. If you reread my comment, you'll notice that it wasn't focusing on the particular syscall that the system uses.
> Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve.
Because of (a), (b), and/or (c), which I addressed in my comment above.
Re: Pencil: A Microframework Inspired by Flask for Rust
#38Earlier quoted context omitted.
But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. So you're not forced to store all the thread's stacks and you don't have expensive context switches. As the parent illustrated, even with Go using nonblocking I/O, it's perceived benefits in that area isn't that great because Go still semantically has a thread-per-connection. So the performance…
>But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. One reason, not the only, or the most important. The primary advantage of non blocking IO is that the CPU isn't sitting idle while waiting for an IO operation to complete. We aren't wasting an entire core to write the response.
That's not how blocking I/O works! Sitting in a busy loop on the CPU burning power polling the I/O device was, like, how the Apple II may have worked, but it hasn't worked like that on any major OS since at least 1990. Operating systems perform context switches on I/O.
Re: Pencil: A Microframework Inspired by Flask for Rust
#39Earlier quoted context omitted.
Switching to asynchronous I/O isn't going to magically result in better performance on HTTP workloads. I don't think most of what any performance difference you're seeing is due to that: I suspect instead that it's relatively "boring" optimization work that has yet to be done in Hyper. The primary difference between async and synchronous I/O is (a) better memory usage due to not having a stack per connection; (b) you…
That's nice and all, but unfortunately the real world tests I've seen (and done) show something like Netty completely trumping anything available for Rust.
1. Are you testing against mio? If so, have you filed bugs against it? At a high level, there is no fundamental design difference between Netty and mio.
2. Netty is worlds away from Golang, precisely for the reasons stated above. Go is a userspace, M:N implementation of per-thread, blocking I/O, while Netty is a truly asynchronous I/O framework. Of course truly async I/O can beat synchronous I/O, but the entire point is that Golang is not strictly async I/O.
Re: Pencil: A Microframework Inspired by Flask for Rust
#40Missed opportunity, should've called it:
"The Blueprint²: The Gift & the Curse"