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

Rails 3 Performance - Not Good Enough

blog.tstmedia.com

Post reply on HN
Print view View original

61–70 of 142 posts

Re: Rails 3 Performance - Not Good Enough

#61

Post by moe »

enko wrote: post #51
moe wrote: post #49

Earlier quoted context omitted.

culture of not giving a shit about performance Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plent…

Well, this comment just comes across as sour grapes to me. You could be criticising any memory managed programming language. Old timers have been complaining about the kids not knowing about assembly, registers, punch cards, valves, etc since computers were invented. As for "incompetent design" - I don't know what you are on about. I think that Rails 3 is a frigging triumph of elegant, modular design. There are very…

You could be criticising any memory managed programming language.

No, I'm explicitly criticizing Ruby. I've spent years in Python-land and the average code quality (and btw documentation standard) is much higher over there. Which is not to say Python doesn't have its own problems, but less so in this particular area.

say that the average rubyist is much more concerned with good design than, say, your average java dev.

Good design is a relative term. In ruby I frequently see it interpreted as: Pack as many layers of magic as possible, and then test that with as many layers of testing-frameworks as possible.

That's not too different from the common architecture-astronouting in java. One could argue it's just a different flavor. In either ecosystem the implementation of the actual business concerns ("What does this code actually do?") too often feels like an afterthought.

Disclaimer: I'm not condemning either language. I like Ruby and use it a lot, but this is one aspect that I can't ignore.

Re: Rails 3 Performance - Not Good Enough

#62

Post by joevandyk »

jpr wrote: post #57
aneth wrote: post #53

I've been a Rails dev for 5 years. I'm frequently considering leaving for another framework because of one thing: bootstrap time. Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD, particularly when you are trying to use tests to track down a bug. In that 20-30 seconds, I often console myself that we no longer need to print punch card…

How often do you need to endure that 20-30 second startup time? Is it every time you change anything?

During deploys, running a test, configuration changes, starting anything that loads the whole rails environment.

Re: Rails 3 Performance - Not Good Enough

#63

Post by joevandyk »

towelrod wrote: post #38
fauigerzigerk wrote: post #17

I think the real problem with Rails and similar frameworks is the culture of not giving a shit about performance. I would never ever release a new version of anything that is significantly slower than the previous one. It's simply a bug in my view. But there are people who have convinced themselves that as long as it scales out, it doesn't matter how many servers you have to run. And if the reason is that something t…

The problems here are manifesting on Ruby 1.8.7, but not 1.9.2. There have been big performance problems found with 1.8.7, for example in this issue: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/... What was originally a performance optimization on 1.9.2 caused a terrible slowdown on 1.8.7. It was reported and fixed within two days. Does that still fit into your "not giving a shit about performance" cr…

Ruby 1.9.2 has its own problems, especially with application startup. My application takes something like 45 seconds to boot on 1.9.2, on 1.8.7 REE it took 20 or so (which still sucks).

http://stackoverflow.com/questions/4789248/rails-3-initializ...

http://stackoverflow.com/questions/5516428/slow-deployment-f...

http://www.ruby-forum.com/topic/1569988

Re: Rails 3 Performance - Not Good Enough

#64

Post by jshen »

ericd wrote: post #18
danielparks wrote: post #12

Earlier quoted context omitted.

In my experience, Rails and frameworks in PHP are quite slow, and typical uses of databases are quite fast. I think it boils down to generality. A database is a very specific thing, and the typical usage of the database (e.g. SELECT * FROM products WHERE id=?) can be very highly optimized. A programming language or framework is much more general, and it is much harder to optimize common cases without losing layers of…

Yeah, 400 ms spent on average just in Ruby on a modern server is really absurd, though. Think about that - half a second, before anything to do with the database. I try to shoot for sub-100ms avg. total, this would probably drive me insane. I don't think I've ever managed to write a PHP page that took more than 100ms on average for the PHP alone on a decent server, and it's not from a lack of abuse.

I have no idea where you get 400ms on average. Here's the log for a blog post page of my site. It's a heavy and big page, it's on ruby 1.8.7 and rails 3, and I haven't done anything to make it faster. I could cache most of it rather easily.

Completed 200 OK in 205ms (Views: 168.9ms | ActiveRecord: 23.2ms | Sphinx: 9.6ms)

edit: a couple of notes. This is running on a cheap vps and would be faster on a real server. It would be faster if I used ruby 1.9 as well. If you want to see how fast a bare ruby webserver is then check out this. http://torquebox.org/news/2011/02/23/benchmarking-torquebox/

Re: Rails 3 Performance - Not Good Enough

#65

Post by theli0nheart »

aneth wrote: post #53

I've been a Rails dev for 5 years. I'm frequently considering leaving for another framework because of one thing: bootstrap time. Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD, particularly when you are trying to use tests to track down a bug. In that 20-30 seconds, I often console myself that we no longer need to print punch card…

I haven't been using Rails for nearly as long as you have. As a result, I thought the bootstrap time was something Rails developers just "put up with". I would have thought that someone else would have noticed this problem and done something about it...surprisingly I don't think many have.

Django, by comparison, bootstraps the environment almost instantly.

I have also been looking for an answer for how to deal with this issue, so I just started a bounty on your question for 200 reputation. Looking forward to a good answer; it may very well convince to go back to Rails.

Re: Rails 3 Performance - Not Good Enough

#66

Post by joevandyk »

aneth wrote: post #53

I've been a Rails dev for 5 years. I'm frequently considering leaving for another framework because of one thing: bootstrap time. Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD, particularly when you are trying to use tests to track down a bug. In that 20-30 seconds, I often console myself that we no longer need to print punch card…

One thing I've been investigating is using RabbitMQ to separate the logic out of the monolithic rails application.

Beetle looks promising. http://xing.github.com/beetle/ You can do both RPC and async messaging. (Might want to wait a few days before using it, there's issues with some libraries that it depends on that will be fixed soon).

Re: Rails 3 Performance - Not Good Enough

#67

Post by glenjamin »

moe wrote: post #59
hyperbovine wrote: post #55

Earlier quoted context omitted.

> On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. Isn't the entire goal of computer science to abstract away complexity?

You can drive a car without knowing how an engine works. But you can't design a [good] car without that knowledge.

I'm not convinced analogies such as this are particularly useful.

I'm pretty sure you could design a perfectly good car by treating an engine as a black box with a clearly defined set of inputs an outputs without caring how those inputs are translated in the outputs. Which is the goal of a framework such as rails.

Re: Rails 3 Performance - Not Good Enough

#68

Post by nirvdrum »

towelrod wrote: post #56
nirvdrum wrote: post #41

Earlier quoted context omitted.

I think your example might actually support the parent's POV more than it refutes his stance. Exception handling isn't just slow in 1.8.7. It may be slower in 1.8.7 than 1.9.2, but exception handling is universally slow. There are a variety of reasons for this, but unrolling an exception is fundamentally slow and until there's native support for them on the die, that's likely to remain the case. So, creating a situat…

>exception handling is universally slow. Except that exception handling is so fast in 1.9.2 that it made this change a performance optimization in 1.9.2. Look lower in this topic for benchmarks showing that Rails 3 is faster in 1.9.2 than rails2 is under 1.8.7. >performance-wise it almost certainly will always be slower Except, it wasn't slower in the Ruby that most people running Rails 3 should be running (1.9.2). I…

I don't really know what your background is, so apologies if I come off as patronizing. If you aren't familiar with how exception handling works under the covers, I encourage you to spend some time looking into it. It's really quite interesting and will likely impact your future design decisions in some way. Learning about longjmp and setjmp clarified a lot of things for me.

Now, I could be completely off-base and 1.9.2 may be the only system out there that has managed to make exception handling a cheap operation. But I'm highly skeptical of that. I think the more likely scenario is exception handling is much cheaper in 1.9.2 than 1.8.7, but still not cheap enough to favor over virtually anything else. I've not read anywhere in the linked issue or in the following comments that suggests using responds_to? was any slower than handling a NoMethodError exception. If it is, that largely points at a failure of responds_to? more than it trumpets the speed of ruby exception handling. And pretending that exception handling is fast enough for flow control and thus other problems needn't be fixed can land a community in serious trouble.

Now obviously there are exceptions to every rule. But the default position of any programmer really should be to reserve exceptions for exceptional circumstances because they are almost axiomatically slow, regardless of language or platform.

Re: Rails 3 Performance - Not Good Enough

#69

Post by aneth »

jpr wrote: post #57
aneth wrote: post #53

I've been a Rails dev for 5 years. I'm frequently considering leaving for another framework because of one thing: bootstrap time. Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD, particularly when you are trying to use tests to track down a bug. In that 20-30 seconds, I often console myself that we no longer need to print punch card…

How often do you need to endure that 20-30 second startup time? Is it every time you change anything?

Pretty much ANYTHING you do. Start a console, start a server, run a test, migrate your database, run a rake task.

It's a huge productivity killer for me. And as other comments have stated, it's surprising this issue is not discussed more.

Re: Rails 3 Performance - Not Good Enough

#70

Post by nirvdrum »

hyperbovine wrote: post #55
moe wrote: post #49

Earlier quoted context omitted.

culture of not giving a shit about performance Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plent…

> On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. Isn't the entire goal of computer science to abstract away complexity?

The goal of abstraction is not to prevent you from knowing what's going on underneath the covers. It's generally to allow you to work on the whole with higher level constructs.

It makes a great deal of sense to understand the complexity you're abstracting away, first. Otherwise, you never really know what you're doing. At the end of the day, you're executing on a computer and you're doing yourself a serious disservice if you're ignoring that fact and hoping either Moore's Law or horizontal scaling are the answer.

Post reply on HN