4 ms·
I had a look at the benchmarks. Could someone confirm -- larger values (bars) means better. So RoR is the worst, and Snap the best on both benchmarks.
by crazydiamond 16y ago
I had a look at the benchmarks. Could someone confirm -- larger values (bars) means better. So RoR is the worst, and Snap the best on both benchmarks.
- chriseidhof 16y agoYes, it's the number of requests handled. More requests served is better.
- acangiano 16y agoWhat was the deployment stack like for Rails? The numbers are way off.
- rufugee 16y agoAgreed...I'm surprised Rails is SOOOO far behind everyone else.
- mightybyte 16y agoI downloaded Rails, followed a few online tutorials to build the app, and ran script/server to run the server. As mentioned in the benchmarking document, we're not experts on Rails deployment and will gladly accept suggestions for improvements that can be implemented in a few minutes.
- acangiano 16y agoYou are running the benchmark with WEBrick, a slow, development only web server. For Rails you should run nginx + Passenger.
- davidmathers 16y agoFor Rails you should run nginx + Passenger No, that's for a production website and requires setup. They just need to replace webrick with thin. > gem install thin then > thin start instead of > ./script/server Simple.
- rufugee 16y agoUm...shouldn't it also be: script/server -e production Running in development mode severely hampers Rails' performance.
- davidmathers 16y agoGood point. I also noticed they're running snap with 4 threads. Since rails is multi-process rather than multi-thread they would actually need to set up something like passenger as acangiano suggested. Better would be to just limit the test to single-process/single-thread. The idea should be to compare web frameworks not web servers.
- mightybyte 16y agoYes, but it's also useful to compare similar levels of effort. Using 4 threads with Snap is a similar level of effort to using thin. Setting up 4 separate processes with passenger requires quite a bit more effort, especially if you haven't done it before.
- davidmathers 16y agoYou can set up 4 processes with thin, just do: > thin -e production -s 4 start The problem is that each process listens on its own port. They can't all listen on port 3000, so you need some sort of proxy to parcel out the requests.
- mightybyte 16y agoI did use -e production, just didn't remember to mention it in the post above. I'll try thin though.
- mightybyte 16y agoI ran the benchmark with the thin server using the following httperf command: httperf --hog --num-conns 1000 --num-calls 1000 --burst-length 20 --port 3000 --rate 1000 --uri=/pong The best I got was 258 requests / sec and 13.5 average responses / sec. The chart on the website plots responses / sec. So thin seems to perform worse. I'm guessing that we're running into the limit of 1024 file descriptors. I didn't test with the libev version of Snap, so my testing had that limit too, but my guess is that Snap is faster and manages to stave off the limit long enough to serve a reasonable number of requests. But I don't know for sure.