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.
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.
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 :)?
I was lucky to get a slice the moment I signed up for it (early adopter I suppose). I have been very happy with their service.
when X page (a problem page) loads, what exact times and % of the total load time is taking place at:
http server
ror, broken down into: activerecord, non-AR logic, & rendering
web browser (pulling down JavaScript files, CSS files, etc)
(calculated for several runs, with perhaps an offpeak benchmark & onpeak benchmark to see if there's a major difference)
Chances are, 80% of your slowness can be alleviated by a few small changes in one of the above areas, but each app is different of course.
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....
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.
I love that there are some people here that seem to think they are entitled to something or that 37s or DHH owes you something. It's open source, you have 3 options: 1. Fix it and get kudos. 2. Don't fix it (because your either too dumb or too lazy) and work around it. 3. Don't use it.
But coming on here and making some generalized proclamation that RoR is slow is irresponsible and unacceptable, IMO.
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.
RoR is not a panacea, but it certainly is "good enough" for a lot of things, think of all the 37 Signals apps.
I wonder, though, if this case of Open Source fury is directly related to the Twitter vs RoR debate, and also to DHHs attitude? Serious question - I don't know about DHH well enough to judge his attitude, it's just a feeling that is in the air.
I'm still not sure what you're trying to say about the Rails framework in general, I've never had an issue using it, or contributing to it.
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.
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.
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.
hahahahahahaha...
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.
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.
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.
Upper mgmt is making us rewrite it in java. (shoot self). It has more to do with what they are comfortable with long term and what the company runs and has the know-how to support.
If I had to do it over again, I'd look at Python more carefully. Django was barely out when we started so we were a bit leery of it. In addition, I didn't have a great impression of Python from doing some toy programs in it. I really liked Ruby's elegance.
Overall, I don't think we would've chosen Java above what we have, warts and all. Java is too verbose and RoR let us be extremely flexible and fast when it mattered.
Outside of upper management intervention, we'd probably have continued down the ruby path and gambled on the fact that things would be fixed/better in a few years.
I feel for twitter, but they're really doing a service for the rest of the RoR community by being the pioneer for extreme scaling issues.
So, just stick to it and wait if you like the beauty keyword "end" and dislike white space vs tab war.
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.