Warning: RoR is slow

https://news.ycombinator.com/item?id=25628

by keiretsu • 19 years ago

21 58 19 years ago

news.ycombinator.com

keiretsu6• 19 years ago

First of all, i don't wish to try to start a flame war. Just want to share some of my experience with RoR.

RoR, to me, is the pinnacle of web programming orgasm. It's fun, it's fast, it's super productive. Hell, i never enjoyed web programming till i tried RoR.

Unfortunately, RoR is slow, or specifically ActiveRecord is slow. No matter how many machines you throw at your app, there is still a noticeable page loading time lag compared to a straightforward PHP script. People hate it. Yes. They do. Users will complain and the only way you can improve the loading time drastically is if you stop using ActiveRecord. But heck, half of the joy in using RoR is with ActiveRecord. Either that or you cache page fragments. But trust me, caching page fragments is not fun. You need to keep track of which fragments to invalidate based on which model actions. Multiply that with many models and you get the same PHP messiness.

So what's my point? My point is that i'm looking for a new FAST mini-framework to replace RoR. Any recommendations :)?

Tichy4• 19 years ago

Groovy on out Grails, perhaps? Not sure about the performance, but at least it uses the Java VM.

davidw3• 19 years ago

What have you tried doing to speed it up? Granted, RoR is no speed demon, but it seems to be "fast enough" for quite a few people. Perhaps you are doing something wrong?

ivan3• 19 years ago

It would be very nice if Ruby would be taken in similar approach as PHP is. mod_ruby for apache and templating system like smarty. that's my orgasm. no frameworks no orm. oh my! :)

antirez2• 19 years ago

You can use mod_ruby + eruby. This is the setup I'm using currently to develop our next application.

mattculbreth• 19 years ago

I agree with another poster--try to speed it up first. You've got a couple caching levels to try, at the page/fragment level and at the ActiveRecord level with memcached.

keiretsu6• 19 years ago

tried caching at the activerecord level with memcached. Yes, there was a speed increase but still there is a noticeable page loading time lag. It doesn't load craigslist fast.

jmcantrell3• 19 years ago

To be honest, it sounds like RoR or ActiveRecord is doing something wrong.

gommm• 19 years ago

First thing, when you use activerecord, do you know and use the include option when doing find?

An example, suppose you have two models Professor, and Lessons A lesson belongs to a professor and a professor has many lessons.

Now, a common mistake is to do things like @professors = Professor.find(:all)

and later to have some code that does something like

@professors.each do |professor| ... professor.lessons ... end

What happens? well you have one request to the database and then one request for each professor. (so the number of request is equal to the number of professors + 1).

If however you do Professor.find(:all, :include = "lessons") it will fetch the lessons right from the beginning and your code will only do one request....

There are a lot of small mistakes like that that beginners do.... And while rails isolate you from the database stuff, you still need to understand what it does if you want things to work well

For more information on all this: http://i.nfectio.us/articles/2006/09/20/mysql-query-analyzer-rails-plugin it's a plugin that you can use to analyze what mysql did (it uses the explain statement for this

http://railsexpress.de/blog/ This blog is a good read.

Cheers....

brlewis• 19 years ago

I've been enjoying web programming for 13 years, most especially the past 10 using BRL, which I wrote. If you're totally in love with ORM it's not for you, though. Basically it's SQL, HTML and as little in between as possible. If you like SQL and Scheme, you'll love BRL.

jdavid• 19 years ago

Active record is also use in Hibernate/nHibernate for java and .net as an o/r (object relational) mapper. There are a number of things someone can do to speed/ or tweek the way that data is accessed. From what I have seen about the web.

You want to design your functions in such a way that you are not doing anything complicated at first. This means that you should focus your API, webservice, or website around operations that perform a single DB call, and are linear in their search time, sometimes page-ation can help too. If you have an api that, for instance tries to find friends of friends, you are opening yourself up to disaster if you are going to do that in real time for a web service. You would be better off offering a service that gives you the friends of a user, pending you have the rights to see that users friends.

Something else we discovered was that if you are using MySQL on a different box in the cloud, your data access times are going to be SLOW, but if you have the DB running on a machine connected through a 1Gb connection you might be alright, but if you have MySQL running on the same dedicated box, then DB calls are almost as fast a calls to memory. Especially if you set up your db connection to connect through some sort of piped call or something similar in linux. At that point your call avoids going through your network interface and you skip the TCP/IP stack, which is a huge latency boost.

bjclark2• 19 years ago

What name are you submitting patches for AR under (I'm not finding any under your username here, http://dev.rubyonrails.org/search?q=keiretsu&wiki=on&changeset=on&ticket=on) ? I'd like to check some of them out to see what your doing. I'm assuming your not just complaining about a free open source project and that your actually doing something about it, since just complaining is pretty bad for your karma.

aston• 19 years ago

It's no longer okay to complain? If I didn't like something, I'd prefer to complain and not use it than waste my time fixing something I find fundamentally flawed.

Tichy4• 19 years ago

While Open Source, I think Ruby on Rails is still a commercial project. Just think about the buzz it generates for 37signals, which probably converts directly to revenue. So I don't see why somebody shouldn't have the right to "complain" about it, or have an opinion about it, or decide to use something else.

Maybe the 37signals don't give a damn about who is using their framework. That would also be an indicator against using it, because it would mean bad support. If they do care about who is using it, then they might also care about people's opinions about it. I think Open Source projects DO compete - just think about the submissions you request. If an open source project is not popular, nobody will submit patches or features for it, either. Then it won't grow, and eventually die.

falsestprophet• 19 years ago

What an excellent demonstration

jamongkad3• 19 years ago

Why don't you try Code Igniter? Heard pretty good reviews about it. It's a framework for PHP.

jamongkad3• 19 years ago

Dunno how to edit my own comments but....Code Igniter comes with excellent documentation I might add. Initially I loved Rails but migrated to Code Igniter cuz it's lightweight and loosely coupled(You don't even need to run with a model if you choose to but it follows the MVC structure quite well).

Plus it outperforms Rails in the speed department. It doesn't sport much magic compared to Rails. But that's ok if you're like me and you want to keep looking under the hood and see how stuff runs on CI. And it doesn't constrain you as much if you want to stretch out and really make it run.

It actually made PHP fun to learn(if you don't mind the fugly syntax). It also supports Active Record btw.

AF2• 19 years ago

Unless you've really got a Ruby fetish, there's just not much of a reason to use it.

If you want a similar language with similar productivity, Python gives you that and speed, Unicode support at the language level, and lots of libraries.

And in web frameworks alone you've got Django, Pylons, Turbogears, web.py, etc. Django has the community and 'push' that Rails does in the Ruby world, and Pylons feels a lot like Rails. So what are you waiting for? Checking them out can't hurt anything.

jamesbritt• 19 years ago

I tried Python; didn't care for it. Something just didn't click.

Later on I tried Ruby, and it was a better fit for my head.

There are differences in the underlying design principles of Ruby and Python, and they can make a big difference in how well you internalize the language.

I also took a look at Django, and it struck me as astonishingly clunky compared to Rails and Nitro.

There are issues of aesthetics at play; I can't argue that my taste is right or wrong, but it certainly matters that I use a tool that aligns with it.

jmcantrell3• 19 years ago

"I also took a look at Django, and it struck me as astonishingly clunky compared to Rails and Nitro"

hahahahahahaha...

AF2• 19 years ago

I've used both. I actually think that Ruby is a nicer language in most respects than Python (except for way too many ways of expressing the same thing in syntax), but Python is a much better 'platform'.

Python struck me as somewhat clunky at first, but after working in it for a few months, I didn't really have any issues with the language. I think there will always be initial resistance for anyone using a different language, but I don't think your mind is necessarily set to where one language will fit it and one won't. Imperative programmers moving over to functional languages will find that functional languages don't "fit their mind", but given enough work in one will probably find that their mind changes to where functional aspects make perfect sense.

So I think that's the case with Python. Some people won't find it clunky at all, for those that do, working in it for some time will probably lead to their mind fitting the language better. Personally I'd rather do that than deal with the issues Ruby the platform has.

Anyway, Ruby and Python are a lot more alike than different.

keiretsu6• 19 years ago

yeah. i agree. tried python. the language is really ugly compared to ruby. django just doesn't fit into my brain like RoR does.

gyro_robo• 19 years ago

That's fair enough -- if a language doesn't fit your aesthetic, it's quite a valid reason to use something else.

richcollins• 19 years ago

Hrm most of the posts here show little understanding of Rails. Rendering, not AR is behind most complaints of "slowness". If you want to speed up rendering, limit the amount of redundant Javascript that gets generated, statically generate links, don't generate SQL (eager load) and cache where needed.

asdf3332• 19 years ago

No. As someone who runs a site w/ more than half a million hits a day at times, rails is butt slow. We memcache up the wazoo as well as make other optimizations.

Not only is it slow but there are memory leaks too.

I hope they fix alot of this. We went w/ rails b/c of the elegance, but paid for being on the bleeding edge.

sbraford2• 19 years ago

Can you share the URL of your site?

Just curious - what are your plans going forward?

i.e. continue what you've been doing, rewrite in another language, or what?

Not that this is your scenario, but whenever I'm in a crunch situation, it always feels like the grass is always greener. When you get to the other side... well, you know how it goes.

keiretsu6• 19 years ago

Finally! Somebody who felt the pains of having a popular Rails site. I feel your pain my friend.

jmcantrell3• 19 years ago

Ruby and RoR, slow? This is a no-brainer. Ruby is slow as molasses and RoR is built upon Ruby. Hmmmmm....

jamongkad3• 19 years ago

The implementation of JRuby should fix this concern.

sabat• 19 years ago

There are a lot of valuable comments here.

If I had to summarize what I think is the likely problem, I would say: look into pre-fetching where it makes sense. Databases are often troublesome beasts, and you have to do more management of the data than you would like.

russ• 19 years ago

Something to look into: I don't know if any of you guys went to RailsConf, but one of the goals of Rails 2.0 is to improve AR through the caching of repeated queries at the AR object level.

keiretsu6• 19 years ago

I've already done this. Got a minor speed bump. You have to understand that the majority of the page loading time is in the instantiation of the AR object, not from fetching the db result. At least that's my experience in my app.

dcancel• 19 years ago

I've moved to Django, huge performance difference. Also a simpler stack, apache + mod_python vs the nginx + mongrel or apache/lighttpd + fcgi or etc....

tx2• 19 years ago

How can you so blindly proclaim something like this? In a world of systems programming I got used to people posting stack traces with milliseconds attached to each function call, complaining about something specific. A good example would be GNU glibc's printf() function checking system locale on every call.

Have you ever done any programming before?

Your claim Active Record is slow sounds almost like my computer is slow. How do you know it was ActiveRecord? How did you benchmark? Was it even RoR? Maybe you had another process spinning in an endless loop in the background eating your CPU.

keiretsu6• 19 years ago

maybe because i've time-profiled it? maybe because i've calculated the time it took to instantiate a new AR object for every new db record? maybe because the results show that the AR component took the largest portion of the page loading time?

ricardo• 19 years ago

Your original post doesn't mention any of this. I think it would help everyone understand your point a lot better if you posted a few specifics...

tx2• 19 years ago

Now we are talking. If I were you, I'd try to look at the bigger picture: do all your pages exhibit this behavior? I bet only few of them do. If ActiveRecord object creation time is your bottleneck, your rhtml on those pages must be very-very thin, because typically rhtml render works waaaay slower than active record.

This tells me that you have pages with very little rhtml in them, but they (somehow) require many DB-mapped objects. Sounds like an anomaly to me. But perhaps this is just a nature of your app, in that case dump the slowest objects and don't use ActiveRecord for them.

Another good suggestion was already mentioned few posts back: when creating your objects, load only those attributes that matter.

Good luck, and hope you'll resolve your performance issues.

count0• 19 years ago

To be fair, the current implement of Ruby (1.8x) is slow because it does not compile source code to byte code and run in vm, which will be available in next version (2.0?). Python, on other hand, already use this for a long time.

So, just stick to it and wait if you like the beauty keyword "end" and dislike white space vs tab war.

Warning: RoR is slow

Related Stories