Show HN: Iron, a fast middleware-oriented Rust web server framework

by jonreem • 12 years ago

81 45 12 years ago

zzmp7• 12 years ago

The Iron team is here. Feel free to ask us anything!

necaris3• 12 years ago

I'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?

zzmp7• 12 years ago

We built Iron on top of `rust-http`, but we're excited for `teepee` too, and there are a few others popping up as well.

mercurial4• 12 years ago

Simple 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

eddyb• 12 years ago

I would guess `Arc<Mutex<T>>`, `Arc<RWLock<T>>` and `Arc<SomeConcurrentContainer>` would all work (cloning them is a ref-count - the handle gets copied, not the contents).

jonreem6• 12 years ago

You are looking for https://github.com/iron/persistent, which offers two utility middleware for exactly this.

zzmp7• 12 years ago

We have a middleware for that! You can look at http://github.com/iron/persistent, which does wrap an RWLock in an Arc. It also provides a struct to make your middleware Share, so you can do similar things.

We also have session, which works on a HashMap under an Arc, although it isolates the mutable data to a session, instead of sharing it across isolated requests.

DomreiRoam• 12 years ago

Do you plan to support handling XML? I mean XSLT transformation, XPath routing, XQuery?

geertj• 12 years ago

Please don't!

dawkins• 12 years 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• 12 years ago

Since the tests are relative they should include a script that tests the different frameworks/languages. It shouldn't be too complicated.

jonreem6• 12 years ago

The 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.

mercurial4• 12 years ago

It 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.

sanderjd• 12 years ago

The 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.

mercurial4• 12 years ago

By 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 should link to http://docs.ironframework.io/router/, instead of http://docs.ironframework.io/core/router. To add insult to injury, 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.

leccine• 12 years ago

Same 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.

Argorak2• 12 years ago

I 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.

chrismorgan2• 12 years ago

At that time, Rust’s TCP support was flaky and easy to crash; it was the issue normally, not rust-http.

pcwalton• 12 years ago

In 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• 12 years ago

I 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/compar...), on my box.

A spreadsheet: https://docs.google.com/spreadsheets/d/1-5_4wPPKNBYZ6yuw-rRl... The raw data: https://gist.github.com/cmr/3648bcc6365c1dba83f1

The charts themselves: 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

wc-2• 12 years ago

This 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?

jonreem6• 12 years ago

We 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.

zzmp7• 12 years ago

We 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-2• 12 years ago

I know rust is pre-1.0 but wow that's a lot more breaking changes than I expected...

bhauer• 12 years ago

I'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

zzmp7• 12 years ago

This 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.

necaris3• 12 years ago

I might help out with this too -- I've been learning Rust recently and I suspect this would help me get up to speed a bit more.

Show HN: Iron, a fast middleware-oriented Rust web server framework

Related Stories