Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Actix: a small, pragmatic, and fast Rust web framework

actix.rs

Post reply on HN
Print view View original

81–90 of 125 posts

Re: Actix: a small, pragmatic, and fast Rust web framework

#81

Post by simooooo »

jason_oster wrote: post #59

I evaluated a few different Rust web frameworks, where performance was the deciding factor. A minimum viable echo server was put through its paces with `h2load` on a relatively recent MacBook Pro. `actix-web` was literally 100x faster than the next fastest competing framework. The benchmark result really confused me. But you'll find that the `actix` actors are extraordinarily lightweight and highly optimized around t…

https://www.techempower.com/benchmarks/previews/round16/

Very fast for plaintext but not as impressive when db queries are involved, i.e. the "fortunes" test

Re: Actix: a small, pragmatic, and fast Rust web framework

#82

Post by masklinn »

topspin wrote: post #45
stusmall wrote: post #5

What a great looking site. I've been really exciting about actix for a while now. We just started some internal experiments with it here and I'm looking forward to more.

Agreed. Good site. This is an aside, and I sincerely apologize for that, but I am compelled... I'm reading the greeting/hello-world example on this nice site and I notice unwrap_or(). That is a poor name: can it panic, as suggested by the "unwrap" part (I have just enough Rust to know that,) or can it not, as suggested by the "or" part? The name is inherently ambiguous! It's as if the .unwrap() that is festooned thro…

For prefixes, unwrap mean Option -> T while or means Option -> Option[0].

For suffixes, "else" means executable code (a closure).

> > It's as if the .unwrap() that is festooned throughout such example Rust code has become so ubiquitous that someone felt it had to be used and so tacked on "_or". Why couldn't it just be .or() or perhaps .default()?

Because Rust doesn't have function overloading and thus you'd be missing most of the cases?

[0] or more generally Wrapper -> T and Wrapper -> Wrapper

Re: Actix: a small, pragmatic, and fast Rust web framework

#83

Post by skolemtotem »

empath75 wrote: post #41
reacharavindh wrote: post #40

Earlier quoted context omitted.

Yes, I'm not constrained in any way to not be able to run a 5 MB binary. I was curious if that was an indication of what is to come for large projects... I guess I was tangentially pointing to complexity and abstraction there.

rust doesn't use dynamic linking, which contributes a lot to that size.

This is pedantic, but rust does link dynamically, but only to libc.

Re: Actix: a small, pragmatic, and fast Rust web framework

#84

Post by oblio »

reacharavindh wrote: post #33

I have just started playing with Actix-web. Rust-Noob as well. The yellow world example compiled to a binary that was ~ 5 MB. As a general case, Actix-web pulls in a lot of dependencies at install, and compile time.Are all of those dependencies really necessary for a hello world scenario? Being a Rust newbie, I thought maybe I was using the wrong tool and started to look at hyper instead..

> I have just started playing with Actix-web. Rust-Noob as well. The yellow world example compiled to a binary that was ~ 5 MB.

I've only played around with Rust a bit, but IMO, as a general rule: don't judge back-end frameworks by the size of the deliveries, unless we're talking about something ridiculous (5GB). It's extremely superficial and has a very low correlation with the quality of the actual tool.

Re: Actix: a small, pragmatic, and fast Rust web framework

#85

Post by steveklabnik »

znfi wrote: post #78

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…

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

Re: Actix: a small, pragmatic, and fast Rust web framework

#86

Post by rkangel »

sudeepj wrote: post #57

> fn greet(req: HttpRequest) -> impl Responder Nice to see front page example using 'impl', the recent most improvement in ergonomics. Before 1.26 things would be different. This makes me more appreciative of the efforts from Rust team/community to improve the ease of use.

To explain this to people who don't know the background - this is about 'impl NameOfTrait' in the return position.

It allows functions to return an object that provides a certain interface without specifying the actual type of that object. This was only previously true by wrapping it in a 'box', which meant a heap allocation and dynamic dispatch. The 'impl trait' provides static dispatch and no other overhead, so produces equivalent code to returning the type directly, but with all the abstraction flexibility that you want.

Re: Actix: a small, pragmatic, and fast Rust web framework

#87

Post by cies »

nevi-me wrote: post #15

I've had relatively good success moving some microservices from Kotlin to Rust (mainly saving about 90% resident memory util). I picked up Actix recently, and so far I'm enjoying using it. If Rust library support for geospatial tools was as good as turf.js, I'd be able to move a lot more stuff into Rust.

> mainly saving about 90% resident memory

The TechEmpower benchmarks do not care for mem usage and startup time. Maybe this has something to do with them doing JVM consulting? :)

Re: Actix: a small, pragmatic, and fast Rust web framework

#88

Post by cies »

tuananh wrote: post #60
kibwen wrote: post #16

Earlier quoted context omitted.

Have you spoken with the Rust core team about Microsoft's use of actix? They love getting feedback from commercial users, and I believe they are willing to sign NDAs when necessary (there's certainly plenty of commercial users they seem to be unable to tell me about, and I ask often :P ). I'm happy to put you in touch with them if you'd like; see my email in my HN profile (and this invitation goes for anyone else out…

He's the author of actix

So MSFT uses Rust. :) That's actually quite a newsworthy thing, could be a lot more newsworthy if we knew the purpose it was used for was some mission critical component that also needs to be blazing fast.

Looking at Rust's strengths, and that MSFT has languages/compilers of it's own, the use case is prolly "mission critical component that also needs to be blazing fast". But for now we're guessing.

Re: Actix: a small, pragmatic, and fast Rust web framework

#89

Post by znfi »

steveklabnik wrote: post #85
znfi wrote: post #78

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…

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

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

Re: Actix: a small, pragmatic, and fast Rust web framework

#90

Post by MrBuddyCasino »

nevi-me wrote: post #29
MrBuddyCasino wrote: post #25

Earlier quoted context omitted.

Whats your driver? Do you save enough server resources do make it worth it, or is it just a hobby project?

I run a public transport website that includes a few mobile apps. I've broken it down into quite a few microservices, but the bulk of it runs on Node and JVM. I have a 64GB RAM, 12 core server, and the JVM services take up about 25% of resident RAM (ignoring Kafka and other Java stuff). I've wanted to learn Rust for a while, so I recently bit the bullet. I use gRPC everywhere (Dart/Flutter, Node, JVM, Python), so I d…

Thanks, situation is similar for me - a 5€ Digital Ocean Droplet (1GB RAM) goes much farther with Rust services than JVM based ones.

FYI: https://nevi.me/ errors out with a 502.

Post reply on HN