[Mongrel] Application performance

Kirk Haines wyhaines at gmail.com
Fri Sep 1 10:07:27 EDT 2006

On 9/1/06, Tim Perrett <tperrett at butlerandtanner.com> wrote:

> If im needing to boost performance how might one go about doing it?

35-38/second can move a lot of traffic, as has been mentioned, so long
as it's 35-38/second for your dynamic traffic, and your static files
are much, much faster.

However, when you benchmark 35-38 requests per second, how many
concurrent requests are you handing?  Can you get 35-38/second with
one request at a time, or do you need several concurrent requests to
get that speed?  How long does it take to actually render a page from
your application, from the time the request goes into Rails to the
time that it comes out?

That latency can make a big difference in the apparent speed of your
application, even if your total throughput is good.

As for how to speed up page rendering, is there anything that you
query from the database that you can cache to avoid db traffic during
a hit?  That can make a very significant difference.  It doesn't
matter if you can render 300 pages per second of plain text if, when
you do the required db activity, the db bottlenecks you down to 10% of

Within your Ruby itself there are some easy things that can make differences.

If you use inject() anywhere, benchmark that usage.  inject() can be
elegant as heck, but it's also often as slow as it is elegant, and it
tends to create a lot of junk objects that have to be garbage
collected.  It can sometimes be phenomenally slow compared to a
solution that doesn't use it.

Do you do any string creation, aggregating from smaller pieces?  Use
<< instead of +.

In hash lookups with strings, hash dups the key.  If you give it a
frozen string it's faster.  If you do a lot of hash lookups this can
add up.

In general, try to be aware of your frivolous object creation.  Ruby
isn't terribly slow with object creation, but it's still more
expensive to use a new object than to reuse an old one, especially
when garbage collection is taken into account.

But before you spend too much time on any of that, take a look at what
you can do to cache your database transactions in order to minimize
them.  If that is the bottleneck, everything else is a meager drop in
the bucket.

Kirk Haines

More information about the Mongrel-users mailing list