From: Richard Conroy Date: 2007-10-02T21:38:32+09:00 Subject: Re: Ruby vs. PHP On 10/1/07, Marcin Raczkowski wrote: > > But you have committed to an ActiveRecord rewrite, and your reasoning > > is not clear. It sounds like you have read something that 'ActiveRecord > > doesn't scale' without investigating thoroughly. > > I didn't "hear" anything, i performed tests and benchmarks, with few > ORMs (AR, Og, sequel) and pure postgres library and obviously pure hand > made SQL is best - of course i can use AR's find_by_sql, and sometimes i > do but it's slower then pure call. Yeah, but slower for which end, the Database or the Rails pizza box? Pursuing as-optimal-as-possible can introduce issues elsewhere. In general Rails ActiveRecord just needs to be 'fast enough' - i.e. not be the bottleneck. > > > > Rails gets a lot of its productivity from ActiveRecord. By getting rid of it, > > you lose that, and you also close the door on the community development > > of ActiveRecord and its supporting plugins. > > > > > I'm planning to use ORM, and use pure sql for most frequent calls (like > checking for new messages, or new stories) that are made by ajax Thats a bad design. The most frequent calls should be hitting your memcache. If you have already rendered the new messages resource once, then it should be in your memcache. Subsequent calls to the resource should return the cached result, no Rails rendering or DB requests involved. You cannot scale big without memcaching. It should be factored into your design already.