10 ms·
Show HN: Iron, a fast middleware-oriented Rust web server framework
- dawkins 12y ago"Iron averages 2500-3000+ requests per second for hello world" For a hello world in my laptop I can get typically 30k requests with Go, and with mono/httpListener ~10k. I expected it to be much faster.
- eudox 12y agoSince the tests are relative they should include a script that tests the different frameworks/languages. It shouldn't be too complicated.
- deleted 12y ago[deleted]
- jonreem 12y agoThe benchmarks are a bit lower than we wanted. I think this is mostly due to an immature ecosystem for doing basic http - working off of c bindings to a proven, fast framework would probably speed this up by a few times.
- mercurial 12y agoIt does sound odd that you compare your framework to NodeJS framework. Comparing to Java frameworks (a fast language which can do both parallelism and concurrency) would be much more relevant.
- jonreem 12y agoTo be honest, it's mostly because that's what we had experience with.
- sanderjd 12y agoThe comparison with Go is really interesting because I don't think its http server does anything particularly fancy (like calling across FFI to non-Go code) and I don't see any obvious bottlenecks in rust-http that would cause an order of magnitude less throughput. Would be interesting to see some profiling.
- ben0x539 12y agoAs far as I can tell (and have been told), rust-http starts a new task (thread, here, really) for every request. Edit: but see https://news.ycombinator.com/item?id=7978299 https://news.ycombinator.com/item?id=7978299
- oscargrouch 12y agoMaybe redesign it to start some thread early, and put them in a pool.. then dispatch to them.. i think i've saw a thread pool already backed in rust std or in servo.. dont recall right.. i think servo even have a fancy work stealing thread pool.. Also the design of Nginx is sophisticated, because it uses the event io + a thread dispatch design.. (at least it was like this last time i've hacked it) and worth being copyied
- mercurial 12y agoBy the way, something is up with the server serving the static doc. The link to the docs is wrong, eg https://github.com/iron/router https://github.com/iron/router should link to http://docs.ironframework.io/router/ http://docs.ironframework.io/router/, instead of http://docs.ironframework.io/core/router http://docs.ironframework.io/core/router. To add insult to injury, http://docs.ironframework.io/core/router http://docs.ironframework.io/core/router returns 200 with an empty body instead of 404. That said, the framework itself looks interesting, though the 'iron/alloy/etc' terminology is a little bit of an annoyance.
- zzmp 12y agoThanks for the heads up. We reworked our folder structure after writing the READMEs, and it looks like we forgot to update. I'll get working on that. The 200 is being served as the default of `rust-http`. Static will never serve a 404 - it will only defer to the next middleware, and the docs server is overly simple, so it just goes to default.
- zzmp 12y agoThis should be fixed. Thanks again.
- leccine 12y agoSame here, without even looking into what is slow, Clojure with Compojure does 7500 req/s. If Rust would like to be the next close to bare metal language we need some serious performance improvements.
- Argorak 12y agoI am not surprised. Most of the machinery necessary for such things is still developing in Rust. When I was testing my now-discontinued framework (widmann) using a very early version of rust-http, I felt lucky when it didn't drop or break on half of the requests. Reliability comes before performance in this regard and Rust is a bit from done. I expect that to develop quickly once the general shape of code is known and people start profiling and optimizing.
- chrismorgan 12y agoAt that time, Rust’s TCP support was flaky and easy to crash; it was the issue normally, not rust-http.
- Argorak 12y agoThat wasn't a complaint, just an illustration on how things are quickly improving. Yes, it was a TCP issue, but presented to me through rust-http.
- pcwalton 12y agoIn our benchmarks our raw TCP performance has generally been best-of-breed. I suspect the issue is rust-http, which is not an official package.
- cmrx64 12y agoI suspect the issue is Iron, though rust-http certainly isn't helping much. Here are some graphs, generated from data made by rust-http's benchmarking script (https://github.com/chris-morgan/rust-http/tree/master/comparisons https://github.com/chris-morgan/rust-http/tree/master/compar...), on my box. A spreadsheet: https://docs.google.com/spreadsheets/d/1-5_4wPPKNBYZ6yuw-rRlg72bfLCpf6NOlAUy9jDDe5A/edit?usp=sharing https://docs.google.com/spreadsheets/d/1-5_4wPPKNBYZ6yuw-rRl... The raw data: https://gist.github.com/cmr/3648bcc6365c1dba83f1 https://gist.github.com/cmr/3648bcc6365c1dba83f1 The charts themselves: http://imgur.com/gw1mp40,Hn3929i,h2OQiTh http://imgur.com/gw1mp40,Hn3929i,h2OQiTh Software versions: rustc 0.11.0-pre (44ec28cfac9fa3f738e0e77ccca1d804125fd1dd 2014-07-01 21:26:33 +0000) go version go1.3 linux/amd64 node v0.10.29 Apache 2.4.9 wrk 3.1.0 Arch Linux, x86_64, CPU: https://gist.github.com/cmr/7cc6df806caff2253667 https://gist.github.com/cmr/7cc6df806caff2253667
- jonreem 12y agoIt's worth mentioning that I ran this under -c 100 or 200, not 1-8, which may change things significantly.
- jonreem 12y agoI just re-ran benchmarks using wrk instead of ab and I'm getting 16k req/s instead of 2k. Very strange.
- glandium 12y agoDid you try changing the runtime to libgreen? It uses a thread pool and dispatches jobs to them instead of spawning a new thread for each job.
- zzmp 12y agoThe Iron team is here. Feel free to ask us anything!
- necaris 12y agoI've been curious about the HTTP implementation, particularly considering that `rust-http` is in bugfix-only mode and `teepee` is still in design phase. Did you folks build it from scratch?
- zzmp 12y agoWe built Iron on top of `rust-http`, but we're excited for `teepee` too, and there are a few others popping up as well.
- bjz_ 12y agoAre you planning on lending assistance to Teepee? We are kind of in limbo in terms of http right now and it would be a shame for Teepee to turn out to be vapourware :( (A hint for any folks experienced with http - this could be your chance to make lasting mark on the Rust ecosystem!)
- necaris 12y agoNot that experienced, but enthusiastic -- does that count ;-)?
- chrismorgan 12y agoTeepee is getting back on track now; I just had a few weeks where I was unable to do much with it, but I started designing and developing things again yesterday.
- mercurial 12y agoSimple question. According to [1], middlewares are cloned for each request. Is there a good built-in way of accessing shared mutable data, such as a connection pool? 1: http://docs.ironframework.io/iron/trait.Middleware.html http://docs.ironframework.io/iron/trait.Middleware.html
- wc- 12y agoThis looks very nice. I've been following rust and go for a while now and I finally have a small service to write that would be a good fit for either language so I'm going to try both. I noticed one of the repo's more recent issues was caused by a change upstream. The upstream rust devs seem very accessible, but how often do you encounter these kinds of breaking changes. Acknowledging that rust is pre-1.0, is there any way to stay up to date on these kinds of changes before they hit your app so you aren't blind sided?
- jonreem 12y agoWe spent a lot of time talking with rust devs on #rust, which is full of extremely helpful, extremely nice people who help you as much as possible. Usually we woke up in the morning to everything broken due to changes in the nightly, but it's pretty easy to grep for [breaking change] and work from there. Most changes take moments to fix.
- zzmp 12y agoWe see these changes every other day or so, but they're usually small syntax changes, and the community's pretty quick to update. A good way to stay up-to-date is always This Week In Rust, or /r/rust.
- wc- 12y agoI know rust is pre-1.0 but wow that's a lot more breaking changes than I expected...
- steveklabnik 12y agoThe rate of change slowed, but then, as we get closer to 1.0, the rate of change has sped back up again. We need to break as many things as possible as soon as possible, so that we can give the community some time to try it out before we christen a 1.0 release. Does that make sense?
- higherpurpose 12y ago
- bhauer 12y agoI've been waiting to see some Rust frameworks emerge. Thanks for putting this together! Would you be willing to contribute a test implementation to our project [1]? [1] http://www.techempower.com/benchmarks/#section=code http://www.techempower.com/benchmarks/#section=code
- zzmp 12y agoThis looks like a great resource! Unfortunately, I'm not sure if anything in Rust should be considered `production-ready` yet, and I haven't worked with any ORM wrappers in Rust (yet). I think we could get tests 1 and 6, if you'd be interested. I'll try to get to those soon.