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.
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.
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.
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.
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 :)?