Actually guys, I took out the queries - except for one that is run once. 
  Same behaviour in top.  I'm going to start marking out the app with 
the benchmark module and hopefully that will shed some light on it!

Robert Klemme wrote:
> Reid Thompson <reid.thompson / ateb.com> wrote:
> 
>> Brian Le Roy wrote:
>>
>>> no, but the table has 140K records.  the disk isn't crunching, so the
>>> index should be okay.  i was thinking it would be passing around the
>>> database connection object causing overhead.  i took the result set
>>> object and created a straight ol' array for passing.  no improvement
>>> - so maybe there's nothing to do.  thanks for all the responses -
>>> i'll keep messing with it and if i find something that improves it,
>>> i'll let you know!
>>>
>>> bonefry wrote:
>>>
>>>> Well, that's it.
>>>>
>>>> MySql can take even 100% of your processing power. It happenes when
>>>> you have complex queries to run, and you run them on big tables.
>>>> Are you running complex queries ?
>>>>
>>>>
>>>>
>>>
>> It may may no difference, but you could try the same with postgresql,
>> or maybe even sqlite, to see if it is mysql thats the issue.
> 
> 
> Before he does that I'd try a different query frontend to see whether 
> performance characteristics stay the same (i.e. time is spent in the DB, 
> which would be my guess).  The overhead is much smaller compared to 
> installing another DBMS, transferring DDL and data to that.
> 
> Kind regards
> 
>    robert
> 
> 
>