thefed wrote:
> 
> On Jan 5, 2008, at 10:29 AM, Gary Wright wrote:
> 
>> Perhaps something like Process::setrlimit is something the OP could use?
>>
> 
> I looked at setrlimit, but it seems to quit the process if it violates
> the conditions. Will it actually prevent ruby from going over 15%
> without killing it?
> 
> 

My last post was semi-facetious ... as it turns out, everything you need
to do what you want to do is built in to Ruby. But as a working
performance engineer, I'm not convinced that what you are trying to do
is either necessary or without risk to the correctness of your
application's behavior.

In other words:

1. Is there in fact a performance problem with your application? There
are many ways to define "performance problem", but what I'm talking
about here is whether the *end-users* experience unacceptable response
times for the tasks they are trying to get done. If they are happy with
response times, you're done -- there is no problem.

2. So ... assume they are unhappy. If you look at a task's lifetime,
you'll generally see that it starts with a user pressing a button or
clicking a link after having typed something in somewhere. That sends an
HTTP request to the web server, which vibrates around in the guts of
Rails, possibly does some CRUD with the database, generates an update to
the screen, and sends a bunch of stuff back to the user.

What you need to do is break this life cycle down into its components
... network time to the servers, processor time, disk time and network
time from the servers back to the end user. The good news is that you
don't really need to worry about memory at this point -- Ruby and the OS
will worry about this for you. :)

3. You will usually find that one component -- network traffic over slow
links, processor time in the Ruby interpreter or the database, or disk
time in the database -- is the largest one. We call this the *primary
bottleneck*.

Now let's say, since you originally asked how to reduce your Ruby usage
to 15 percent of the CPU, that you've determined that the primary
bottleneck is the Ruby processor time. If you limit that to 15 percent
of the CPU, your application will become *less responsive* than it was
when it was allowed to use as much as it needed!

Instead, what you need to do is profile the Ruby script, using the
profiling tools built in to Ruby/Rails. This is covered in a number of
books, so I won't go into it here. The point is that you need to define
the problem, if indeed there is one, and use a *systematic* approach to
solving it.