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

Is Ruby Fast Yet?

isrubyfastyet.com

Post reply on HN
Print view View original

51–60 of 95 posts

Re: Is Ruby Fast Yet?

#51

Post by sluukkonen »

jrochkind1 wrote: post #27
sluukkonen wrote: post #25

Earlier quoted context omitted.

Looks like it's running with the threadsafe mode off. That would probably give JRuby an edge, as it's able to take advantage of greater thread parallelism than MRI. No idea if he's letting the JVM warm up enough either.

Depending on how you are deploying the ruby app. As far as I know, Passenger Enterprise and Puma are the only multi-platform ruby rack app servers that support multi-threaded concurrent request dispatch. There may be other jruby/java-only deployment scenarios that support concurrent request dispatch. Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-pe…

> Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-per-second benchmarks. Also, the benchmarking test would have to be willing to issue requests concurrently!

That's a good point.

That said, JRuby would most likely benefit from a concurrent test, as the thread-per-request model of JRuby can scale much higher than the process-per-request model which is used a lot in the MRI world.

Re: Is Ruby Fast Yet?

#53

Post by bch »

bch wrote: post #46
Freaky wrote: post #23

Earlier quoted context omitted.

A lot of optimizations are off by default, or completely unavailable because he's using JDK 1.6. See https://github.com/jruby/jruby/wiki/PerformanceTuning Startup time is slow because it needs to warm up the JIT. Same with Rubinius, which is mysteriously missing from most of these graphs. Memory consumption partially depends on how much you tell the JVM to use - it'll run the garbage collector more or less aggressive…

> Startup time is slow because it needs to warm up the JIT. Question (I'll end up simultaneously googling...): if the code doesn't change between restarts, is there a way one can preserve JIT statistics, so the JVM doesn't have to rediscover hotspots? Like an RDBMS able to load custom statistics for its plan engine.

Replying to self: Looks like Microsofts .net NGen _tends_ towards what I was imagining:

http://en.wikipedia.org/wiki/Native_Image_Generator

Re: Is Ruby Fast Yet?

#54

Post by lowglow »

awj wrote: post #49
lowglow wrote: post #35

[serious] I'm building http://techendo.co/ and it's running rails on heroku. I was wondering if there was some easy ways to get some better performance out of it immediately now that we're picking up traffic. If anyone could give me some pointers or link me to a page I'd appreciate it.

That's an incredibly broad question, so it's pretty hard to answer. Here's some general ones: * More instances will give you more requests/second, but only so long as secondary system (database, search server, whatever) can keep up with the load * N+1 queries will kill your performance. They can add a lot of time to processing requests. * Everything in the most used parts of your site should hit an index on the datab…

Thanks. :)

Re: Is Ruby Fast Yet?

#55

Post by briantakita »

x1024 wrote: post #37
yuvipanda wrote: post #7

5s startup time for a web framework seems rather high. I wonder how well it compares to similar frameworks in other languages (Django? ASP.NET MVC?)

Eh... no it doesn't.

It is when your development process involves rapidly iterating the code by running the process many times (i.e. TDD). Anecdotally, when the feedback loop is tighter, I'm much happier. Developing (especially refactoring) in Rails feels like watching paint dry, since it's soooooo slooooow. Every time the process needs to restart, I'm left hanging........waiting......for..............the.............. ..........process.......................to.................... ...................................................s.......... ................t.............................a............... ..............r............................................... ..tttt...........

Also the benchmark is the best case. In real world projects, I've seen Rails take over 60 seconds to start (it took a few days of development effort to bring it down to ~20 seconds). Every time you rerun tests, run a rake task, start or restart your server, etc. It's like the heartbeat of the development process grinds to a halt when you add more features to your Rails server.

And no, tools like Spork are not the answer, since you still have to balance the amount that is resident in memory to fork with coverage of what you can change. It also opens up a fractal of complexity.

Re: Is Ruby Fast Yet?

#56

Post by bhauer »

sluukkonen wrote: post #48
RyanZAG wrote: post #36

Earlier quoted context omitted.

Ah, that explains it. Pretty massive difference really. I guess that makes Torquebox+JRuby the best way to run ruby code? I wonder why the RoR community generally ignores it? Maybe it's just a timing thing and as more companies learn about Torquebox they will swap?

I'd wager that it's the TB/Undertow code running most of the time on that benchmark. On real-world benchmarks the difference is going to be a lot smaller. Not saying that you shouldn't run your JRuby apps on Torquebox - it's a great choice.

Indeed. In our tests, the plain Rack implementation is extremely impressive, but that is probably because there is so little Ruby code being run [1]. By contrast, the Rails implementation on JRuby is just a bit better than plain Ruby, but that is an improvement versus our previous rounds that were not using TorqBox. Previously, we had been using JRuby deployed on Resin, and the results put that JRuby+Rails combination slightly slower than plain Ruby+Rails. For what it's worth, Resin is fast as far as Java Servlet containers go.

Since TorqBox/TorqueBox 3 is very new, I don't suspect it's being used much yet.

[1] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

Re: Is Ruby Fast Yet?

#57

Post by tawm »

briantakita wrote: post #55
x1024 wrote: post #37

Earlier quoted context omitted.

Eh... no it doesn't.

It is when your development process involves rapidly iterating the code by running the process many times (i.e. TDD). Anecdotally, when the feedback loop is tighter, I'm much happier. Developing (especially refactoring) in Rails feels like watching paint dry, since it's soooooo slooooow. Every time the process needs to restart, I'm left hanging........waiting......for..............the.............. ..........process.…

Oh god. Please edit your comment so it doesn't break the whole layout.

Re: Is Ruby Fast Yet?

#58

Post by tibbon »

lowglow wrote: post #35

[serious] I'm building http://techendo.co/ and it's running rails on heroku. I was wondering if there was some easy ways to get some better performance out of it immediately now that we're picking up traffic. If anyone could give me some pointers or link me to a page I'd appreciate it.

Make sure you're running New Relic or another monitoring service that can give you some insight into various parts of your application. If you can't see what is slow, then you can't fix it.

Fixing bad queries (n+1 is a common thing that will get you in trouble), and caching API calls (Rail.cache.fetch is your friend) will help a ton.

Background any tasks that must be slow. I like using Resque/Redis myself.

At some point it helps to cache HTTP requests when possible too. I've been working trying to get a special Buildpack working with Nginx for better caching on Heroku, but I'm not done yet. Also make sure that you aren't serving static assets from Heroku, and you're using something like CloudFront for it.

Email me if you need more help. I can normally make these things fly.

Re: Is Ruby Fast Yet?

#59

Post by noelwelsh »

If you're going to call it "Is Ruby Fast Yet", you should really be comparing Ruby implementations to implementations of other programming languages. Asked this way, I believe the answer to the question is a definite "no".

As a small example, I benchmarked a real Scala web app running on worse hardware (a 1GB Linux VM) at over 650 requests/s. There was no degradation in load at this rate of requests, but it was 10x the load we saw in production so I stopped there. The benchmark of Rails here goes to ~120 requests/s.

Post reply on HN