[Mongrel] Application performance

Ezra Zygmuntowicz ezmobius at gmail.com
Fri Sep 1 12:12:06 EDT 2006


On Sep 1, 2006, at 8:58 AM, Ezra Zygmuntowicz wrote:

> HI~
>
> On Sep 1, 2006, at 7:07 AM, Kirk Haines wrote:
>
>> 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
>> that.
>>
>> 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
>
>
> 	Very good stuff Kirk. I'll mention a few things from my attempts to
> speed up rails applications. When you look at a rails app like the
> one being discussed you need to realize that the view templates are
> getting rendered every hit if there is no caching. How heavy are your
> views? Using a ton of link_to and all the other helpers is very nice
> to work with but can kill your performance. I am workign on an app
> with almost no caching and tons of ajax. After benchmarking it turned
> out that rendering the view templates was actually taking around 60%
> of the total time rails spent servicing a request. By switching a
> number of link_to's into <a href>'s and replacing a few other heavy
> helpers with there normal html equivalents and writing some actual
> javascript instead of using too many js helpers really cut down on
> render time. This is one of the most important things to look at in a
> rails app that cannot use caching. I have also had some great
> template speed ups from using Stephan Kaes excellent Template
> Optimizer[1].

Gah! Sorry forgot to include a link in the last email:

[1] http://railsexpress.de/blog/articles/2006/08/15/rails-template- 
optimizer-beta-test#comments


-Ezra




More information about the Mongrel-users mailing list