Comments on: Lourens Naudé on the Best ActiveRecord and Fragment Cache Store http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/ Random musings on Webapps. Tue, 14 Oct 2008 13:22:18 +0000 http://wordpress.org/?v=2.6.2 By: Lourens http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-8 Lourens Wed, 20 Dec 2006 07:56:46 +0000 http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-8 Oliver, I think AR slowness is inherited by the language, more specific Garbage Collection.Depending on the size of the result set, there's a good chance Garbage Collection could be triggered after conversion of raw result to AR objects. http://beaver.net/slides/ruby/ruby-gc-slides.pdf http://seattlerb.rubyforge.org/mem_inspect/ Complex joins is catch 22 ground.Object caching (memcached) just unmarshals the AR object and is unlike to trigger GC as often, but is only well suited for single row queries or the odd couple of rows.Fetching via AR would likely trigger GC in a scenario where one Mongrel/FCGI processes the same db intensive (multiple joins etc. ) action at regular intervals. The performance difference between Model.find_by_sql ( conversion to AR object ) and Model.connection.execute ( raw MySQL result ) is also significant. Applying http://railsexpress.de/blog/articles/2006/10/05/make-ruby-mysql-create-less-garbage to latest ruby-mysql tarball ( requires MySQL devel libs >= 5.0.27 ) would also cut down on large JOIN retrieval. But of course, none of the above would yield native C performance :-) Oliver,

I think AR slowness is inherited by the language, more specific Garbage Collection.Depending on the size of the result set, there’s a good chance Garbage Collection could be triggered after conversion of raw result to AR objects.

http://beaver.net/slides/ruby/ruby-gc-slides.pdf

http://seattlerb.rubyforge.org/mem_inspect/

Complex joins is catch 22 ground.Object caching (memcached) just unmarshals the AR object and is unlike to trigger GC as often, but is only well suited for single row queries or the odd couple of rows.Fetching via AR would likely trigger GC in a scenario where one Mongrel/FCGI processes the same db intensive (multiple joins etc. ) action at regular intervals.

The performance difference between Model.find_by_sql ( conversion to AR object ) and Model.connection.execute ( raw MySQL result ) is also significant.

Applying http://railsexpress.de/blog/articles/2006/10/05/make-ruby-mysql-create-less-garbage to latest ruby-mysql tarball ( requires MySQL devel libs >= 5.0.27 ) would also cut down on large JOIN retrieval.

But of course, none of the above would yield native C performance :-)

]]> By: Robert Oliver http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-7 Robert Oliver Wed, 20 Dec 2006 04:34:09 +0000 http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-7 We used the regular mysql.h code. We just did mysql queries. I tried it first with MySQL++, but the speed of that isn't much better than AR. I would share the code but it is a closed source project. We used the regular mysql.h code.

We just did mysql queries. I tried it first with MySQL++, but the speed of that isn’t much better than AR.

I would share the code but it is a closed source project.

]]> By: Shanti Braford http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-6 Shanti Braford Wed, 20 Dec 2006 04:32:14 +0000 http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-6 Robert, I'd love to see how you implemented the C version. - Shanti Robert,

I’d love to see how you implemented the C version.

- Shanti

]]> By: Robert Oliver http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-5 Robert Oliver Tue, 19 Dec 2006 21:45:20 +0000 http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-5 Good information Lourens! We definitely took some different routes in our analysis. You know, ActiveRecord, as great as it is, can't be tweaked much. In our experience, if you need intensive DB work on the backend, don't expect AR to come to the rescue. Sure, it's great for the front end, but is painfully slow on the backend. I recently tweaked a project I was working on by writing a plain ol'e C app to do backend processing. I was able to take a 13 second SELECT (complicated join) with AR and turn it into a 1 sec tight loop with C. Got the same work done. Sure it was more lines of code, but if you need intensive backend processing, AR isn't up to the task, yet. I'll be posting some more detailed benchmarks on my site soon. Good information Lourens! We definitely took some different routes in our analysis.

You know, ActiveRecord, as great as it is, can’t be tweaked much. In our experience, if you need intensive DB work on the backend, don’t expect AR to come to the rescue. Sure, it’s great for the front end, but is painfully slow on the backend.

I recently tweaked a project I was working on by writing a plain ol’e C app to do backend processing. I was able to take a 13 second SELECT (complicated join) with AR and turn it into a 1 sec tight loop with C. Got the same work done.

Sure it was more lines of code, but if you need intensive backend processing, AR isn’t up to the task, yet.

I’ll be posting some more detailed benchmarks on my site soon.

]]> By: On Web Apps » Blog Archive » Wisdom of Rails Wizards Study in Best ActiveRecord and Fragment Caching Store http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-3 On Web Apps » Blog Archive » Wisdom of Rails Wizards Study in Best ActiveRecord and Fragment Caching Store Tue, 19 Dec 2006 12:35:03 +0000 http://onwebapps.com/lourens-naude-on-the-best-activerecord-and-fragment-cache-store/#comment-3 [...] Lourens Naudé [...] [...] Lourens Naudé [...]

]]>