khaines / enigo.com wrote:
> On Wed, 7 Mar 2007, Brian Adkins wrote:
> 
>> When running a test that primarily involves loading up a few MySQL 
>> tables with ActiveRecord objects, I was surprised to see the Ruby CPU 
>> utilization at 93% and the MySQL CPU utilization at 7%. I would expect 
>> this workload to be heavier on MySQL than that.
>>
>> I would think inserts (particularly with updating several foreign key 
>> indices) would tax the database more than Ruby.
>>
>> Has this been other folks' experience? Is running in the test 
>> environment incredibly different than production with respect to CPU 
>> utilization? I suppose my next step is to run in production to see 
>> what kind of results I get.
> 
> No, that isn't surprising.  Any ORM trades CPU utilization outside of 
> the database for convenience in the data representation.  AR is fairly 
> heavyweight in that regard, so it's doing a lot of work to give you the 
> API that it does.  Latency to a database can be a significant bottleneck 
> to some applications, but relatively speaking, CPU utilization by the db 
> will usually be a small fraction of the CPU utilization of the ORM using 
> application that is talking with the db.

I agree about ORMs trading CPU for convenience, but I've used other ORMs 
(such as Hibernate with Java), and I don't recall the CPU ratio to be 
quite so high. In fact, my prior experience has always been that a piece 
of code such as I'm using would be database bound, and not CPU bound. I 
mean, seriously, all the code is doing is a bunch of database inserts!

Also, since I'm not using stored procedures with Rails, MySQL has to 
work harder to parse the statements, so if stored procedures were used, 
the Rails/MySQL CPU ratio would be even higher than 93/7.

Frankly, it's not worth my time to whip up a Java/Hibernate example for 
comparison, but I'm pretty darn curious now - both at what the CPU ratio 
would be as well as the time for completion.

I'm willing to live with it, but that doesn't mean I have to like it :)

> 
> 
> Kirk Haines
> 
>